FLATPAK-MANIFEST(5)

๐Ÿ’… FLATPAK-MANIFEST โœจ

okay so bestie, welcome to flatpak-manifest โ€” this is section 5 of the flatpak manual, and it's literally the blueprint page. buckle up ๐ŸŽ€


๐ŸŒธ NAME ๐ŸŒธ

flatpak-manifest โ€” all the info you need for building an application ๐Ÿ‘‘


๐Ÿฆ‹ DESCRIPTION ๐Ÿฆ‹

Flatpak uses manifest files โ€” you might also hear them called recipe files, same thing, no cap โ€” written in json or yaml format. These lil guys describe how an application and its bundled dependencies get built from sources. And who actually eats the manifest? flatpak-builder. that's the one. ๐Ÿ’–


๐Ÿงš FILE FORMAT ๐Ÿงš

The top level of the manifest file is where the tea gets spilled: it describes the global attributes of the application, how it can be built, and the list of modules that need to be built. periodt. โœจ

๐ŸŽ€ Toplevel properties ๐ŸŽ€

these are the properties that get accepted, bestie:

  • id or app-id (string) โ€” a string defining the application id. heads up tho: app-id is deprecated and only preserved for backwards compatibility ๐Ÿ™ˆ (so like, use it if you must, but know it's giving legacy).
  • branch (string) โ€” the branch to use when exporting the application. If this is unset, the default comes from the default-branch option. โš ๏ธ This key overrides both the default-branch key and the --default-branch commandline option. Unless you need a very specific branchname (like for a runtime or an extension), it is recommended to use the default-branch key instead, because that one can be overridden by the --default-branch option. ๐Ÿ’…
  • default-branch (string) โ€” the default branch to use when exporting the application. Defaults to master. This key can be overridden by the --default-branch commandline option. ๐Ÿ‘‘
  • collection-id (string) โ€” the collection ID of the repository, defaults to being unset. Setting a globally unique collection ID allows the apps in the repository to be shared over peer-to-peer systems without needing further configuration. ๐ŸŒˆ If you're building in an existing repository, the collection ID must match the existing configured collection ID for that repository. (no improvising, bestie.)
  • extension-tag (string) โ€” if you're building an extension, this is the tag for the extension point to use. Since flatpak 0.11.4 a runtime may define multiple locations for the same extension point, with the intention that different branches for the extension are mounted at each location. When building an extension it is necessary to know what extension point to install the extension to, and this option resolves any ambiguity in which extension point to choose. If not specified, the default choice is to install into either the only location for the extension point or into the location for the untagged extension point. ๐Ÿซถ If there are multiple locations for the same extension point defined with different tags, then an error will occur โ€” yes, an actual error, she's dramatic like that. ๐Ÿ’€
  • token-type (integer) โ€” the type of token needed to install this commit. Setting this to a value greater than 0 implies that authentication will be needed to install the flatpak. ๐Ÿ”
  • runtime (string) โ€” the name of the runtime that the application uses.
  • runtime-version (string) โ€” the version of the runtime that the application uses, defaults to master.
  • sdk (string) โ€” the name of the development runtime that the application builds with.
  • var (string) โ€” initialize the (otherwise empty) writable /var in the build with a copy of this runtime.
  • metadata (string) โ€” use this file as the base metadata file when finishing.
  • command (string) โ€” the filename or path to the main binary of the application. โš ๏ธ Note that this must be a single executable, not a commandline or an absolute path. If you want to pass arguments, install a shell script wrapper and use that as the command. Also note that the command is used when the application is run via flatpak run, and it does not affect what gets executed when the application is run in other ways, e.g. via the desktop file or D-Bus activation. ๐Ÿ™ˆ
  • build-runtime (boolean) โ€” build a new runtime instead of an application. โœจ
  • build-extension (boolean) โ€” build an extension. ๐ŸŽ€
  • separate-locales (boolean) โ€” separate out locale files and translations to an extension runtime. Defaults to true.
  • id-platform (string) โ€” when building a runtime sdk, also create a platform based on it with this id.
  • metadata-platform (string) โ€” the metadata file to use for the platform we create.
  • writable-sdk (boolean) โ€” if true, use a writable copy of the sdk for /usr. Defaults to true if build-runtime is specified.
  • appstream-compose (boolean) โ€” run appstreamcli compose during cleanup phase. Defaults to true.
  • sdk-extensions (array of strings) โ€” install these extra sdk extensions in /usr.
  • platform-extensions (array of strings) โ€” install these extra sdk extensions when creating the platform.
  • base (string) โ€” start with the files from the specified application. This can be used to create applications that extend another application. ๐Ÿงฌ
  • base-version (string) โ€” use this specific version of the application specified in base. If unspecified, this uses the value specified in branch.
  • base-extensions (array of strings) โ€” install these extra extensions from the base application when initializing the application directory.
  • inherit-extensions (array of strings) โ€” inherit these extra extension points from the base application or sdk when finishing the build.
  • inherit-sdk-extensions (array of strings) โ€” inherit these extra extension points from the base application or sdk when finishing the build, but do not inherit them into the platform. ๐Ÿ‘€
  • tags (array of strings) โ€” add these tags to the metadata file.
  • build-options (object) โ€” object specifying the build environment. See below for details ๐Ÿ‘‡
  • modules (array of objects or strings) โ€” an array of objects specifying the modules to be built in order. String members in the array are interpreted as the name of a separate json or yaml file that contains a module. See below for details ๐Ÿ‘‡
  • add-extensions (objects) โ€” this is a dictionary of extension objects. The key is the name of the extension. See below for details ๐Ÿ‘‡
  • add-build-extensions (objects) โ€” this is a dictionary of extension objects similar to add-extensions. The main difference is that the extensions are added early and are available for use during the build. โฐ
  • cleanup (array of strings) โ€” an array of file patterns that should be removed at the end. Patterns starting with / are taken to be full pathnames (without the /app prefix), otherwise they just match the basename. ๐Ÿงน
  • cleanup-commands (array of strings) โ€” an array of commandlines that are run during the cleanup phase.
  • cleanup-platform (array of strings) โ€” extra files to clean up in the platform.
  • cleanup-platform-commands (array of strings) โ€” an array of commandlines that are run during the cleanup phase of the platform.
  • prepare-platform-commands (array of strings) โ€” an array of commandlines that are run after importing the base platform, but before applying the new files from the sdk. This is a good place to e.g. delete things from the base that may conflict with the files added in the sdk. ๐Ÿซง
  • finish-args (array of strings) โ€” an array of arguments passed to the flatpak build-finish command.
  • rename-desktop-file (string) โ€” any desktop file with this name will be renamed to a name based on id during the cleanup phase. The appdata file launchable will be updated if needed.
  • rename-appdata-file (string) โ€” any appdata (metainfo) file with this name will be renamed to a name based on id during the cleanup phase. The id in the file will be updated as needed and the subsequent provides. (since 1.4.1)
  • rename-mime-file (string) โ€” any mimetypes file with this name will be renamed to a name based on id during the cleanup phase. (since 1.4.0)
  • rename-icon (string) โ€” any icon with this name will be renamed to a name based on id during the cleanup phase. Note that this is the icon name, not the full filename, so it should not include a filename extension. ๐Ÿ–ผ๏ธ
  • rename-mime-icons (array of string) โ€” any mime icons with any of these names will be renamed to a name prefixed with id during the cleanup phase. Note that these are the icon names, not the full filenames, so they should not include a filename extension. (since 1.4.0)
  • appdata-license (string) โ€” replace the appdata (metainfo) project_license field with this string. This is useful as the upstream license is typically only about the application itself, whereas the bundled app can contain other licenses too. ๐Ÿ“œ
  • copy-icon (boolean) โ€” if rename-icon is set, keep a copy of the old icon file.
  • desktop-file-name-prefix (string) โ€” this string will be prefixed to the Name key in the main application desktop file.
  • desktop-file-name-suffix (string) โ€” this string will be suffixed to the Name key in the main application desktop file.

โญ Build Options โญ

Build options specify the build environment of a module, and can be specified globally as well as per-module. โœจ Options can also be specified on a per-architecture basis using the arch property. iykyk.

these are the properties that get accepted:

  • cflags (string) โ€” this is set in the environment variable CFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.
  • cflags-override (boolean) โ€” if this is true, clear cflags from previous build options before adding it from these options.
  • cppflags (string) โ€” this is set in the environment variable CPPFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.
  • cppflags-override (boolean) โ€” if this is true, clear cppflags from previous build options before adding it from these options.
  • cxxflags (string) โ€” this is set in the environment variable CXXFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.
  • cxxflags-override (boolean) โ€” if this is true, clear cxxflags from previous build options before adding it from these options.
  • ldflags (string) โ€” this is set in the environment variable LDFLAGS during the build. Multiple specifications of this (in e.g. per-arch area) are concatenated, separated by spaces.
  • ldflags-override (boolean) โ€” if this is true, clear ldflags from previous build options before adding it from these options.
  • prefix (string) โ€” the build prefix for the modules (defaults to /app for applications and /usr for runtimes).
  • libdir (string) โ€” the build libdir for the modules (defaults to /app/lib for applications and /usr/lib for runtimes).
  • append-path (string) โ€” this gets tacked onto the end of PATH in the build env, with a leading colon if it needs one. โœจ
  • prepend-path (string) โ€” this goes at the front of PATH in the build env, with a trailing colon if needed. ๐Ÿ’…
  • append-ld-library-path (string) โ€” appended to LD_LIBRARY_PATH in the build environment (leading colon if needed). ๐Ÿฆ‹
  • prepend-ld-library-path (string) โ€” prepended to LD_LIBRARY_PATH in the build environment (trailing colon if needed). ๐Ÿฆ‹
  • append-pkg-config-path (string) โ€” appended to PKG_CONFIG_PATH in the build environment (leading colon if needed). ๐ŸŽ€
  • prepend-pkg-config-path (string) โ€” prepended to PKG_CONFIG_PATH in the build environment (trailing colon if needed). ๐ŸŽ€
  • env (object) โ€” bestie it's literally just a dictionary of environment variables to set during the build ๐Ÿซถ. Anything in here overrides the properties that set the environment, like cflags and ldflags. And if a key has a null value? That unsets the variable. Iconic.
  • secret-env (array of strings) โ€” an array saying which host environment variables get transferred into the build-commands or post-install environment. ๐Ÿคซ
  • build-args (array of strings) โ€” extra options to hand to flatpak build. ๐Ÿ”ฅ
  • test-args (array of strings) โ€” same energy as build-args but it hits the tests, not the normal build. ๐Ÿ˜Œ
  • config-opts (array of strings) โ€” extra options passed to the build system during configuration.
  • secret-opts (array of strings) โ€” options passed to configure, specifically for sneaking secrets through host environment variables ๐Ÿ‘€. Environment variables inside the options get expanded. Like:
'-DSECRET_ID=$CI_SECRET'
  • make-args (array of strings) โ€” extra arguments passed to make.
  • make-install-args (array of strings) โ€” extra arguments passed to make install.
  • strip (boolean) โ€” if true, every ELF file gets stripped after install. Default is false, no cap. ๐Ÿ’€
  • no-debuginfo (boolean) โ€” so by default (when strip isn't true) flatpak-builder pulls all the debug info out of ELF files into separate files and drops them into an extension. Wanna kill that? Set no-debuginfo to true.
  • no-debuginfo-compression (boolean) โ€” when it extracts debuginfo, the debug sections get compressed. To turn that off, set no-debuginfo-compression to true.
  • arch (object) โ€” a dictionary that defines a whole separate build options object per arch, to override the main build options. ๐ŸŒˆ

๐Ÿงฉ Extension โœจ

This defines extension points in the app or runtime that extensions can implement, supplying extra files that are available during runtime. So useful fr fr.

Here's what it accepts:

  • directory (string) โ€” where the extension gets mounted ๐Ÿ“. If the extension point is for an application, this path is relative to /app; otherwise it's relative to /usr.
  • bundle (boolean) โ€” if true, the data created in the extension directory gets left out of the result and instead gets packaged into its own separate extension. ๐ŸŽ
  • remove-after-build (boolean) โ€” if true, the extension gets removed once finishing up. This is only interesting for extensions in the add-build-extensions property.

And also โ€” the standard flatpak extension properties are supported, and get dropped directly into the metadata file: autodelete, no-autodownload, subdirectories, add-ld-path, download-if, enable-if, autoprune-unless, merge-dirs, subdirectory-suffix, locale-subset, version, versions. Hit up the flatpak metadata documentation for the deets on those. ๐Ÿ“–

๐Ÿ“ฆ Module

Each module is a source that has to be built and installed separately ๐Ÿ’…. It holds the build options plus a list of sources to download and extract before building.

Modules can be nested, so you can flip related modules on and off with a single key. But heads up: module scopes are always isolated, so nested modules do not inherit attributes from their parents. Not even a little. ๐Ÿ™ˆ

Accepted properties:

  • name (string) โ€” the module's name, used in like build logs and stuff. It's also used to construct filenames and commandline arguments, so putting spaces or / in here is a bad idea. Don't do it bestie. ๐Ÿ˜ญ
  • disabled (boolean) โ€” if true, skip this module entirely.
  • sources (array of objects or strings) โ€” an array of objects defining sources that get downloaded and extracted in order. String members in the array are read as the name of a separate json or yaml file containing sources. More on that below. ๐Ÿ‘‡
  • secret-env (array of strings) โ€” which host environment variables get transferred to the build-commands or post-install environment. ๐Ÿคซ
  • config-opts (array of strings) โ€” options passed to configure.
  • secret-opts (array of strings) โ€” options passed to configure, meant for passing secrets through host environment variables. Put the option with an environment variable and it gets resolved beforehand. Like this:
'-DSECRET_ID=$CI_SECRET'
  • make-args (array of strings) โ€” arguments passed to make.
  • make-install-args (array of strings) โ€” arguments passed to make install.
  • rm-configure (boolean) โ€” if true, yeet the configure script before starting the build. This requires the configure script to actually exist in the source directory. No script, no removal. ๐Ÿšซ
  • no-autogen (boolean) โ€” ignore that an autogen script exists.
  • no-parallel-make (boolean) โ€” don't call make with arguments to build in parallel.
  • install-rule (string) โ€” the name of the rule passed to make for the install phase. Default is install.
  • no-make-install (boolean) โ€” don't run the make install (or equivalent) stage.
  • no-python-timestamp-fix (boolean) โ€” don't fix up the *.py[oc] header timestamps for ostree use.
  • cmake (boolean) โ€” use cmake instead of configure. Deprecated: use buildsystem instead. โš ๏ธ
  • buildsystem (string) โ€” which build system to use: autotools, cmake, cmake-ninja, meson, simple, qmake.
  • builddir (boolean) โ€” use a build directory that's separate from the source directory.
  • subdir (string) โ€” build inside this subdirectory of the extracted sources.
  • build-options (object) โ€” a build options object that can override the global options. Just a reminder: this is not inherited by nested modules. ๐Ÿซ 
  • build-commands (array of strings) โ€” commands to run during build (between make and make install, if those are being used). This is mainly useful when you're on the "simple" buildsystem. Each command runs in /bin/sh -c, so it can use standard POSIX shell syntax like piping output ๐ŸŒ€. If any individual entry in the array fails, the whole build process fails โ€” just like commands in a make(1) recipe.
  • post-install (array of strings) โ€” shell commands run after the install phase. Great for cleaning up the install dir or installing extra files. ๐Ÿงน
  • cleanup (array of strings) โ€” file patterns that get removed at the end. Patterns starting with / are treated as full pathnames (without the /app prefix); otherwise they just match the basename. And ngl โ€” those patterns will only match files installed by this module.
  • ensure-writable (array of strings) โ€” here's how the builder works: files in the install directory are hard-links to the cached files, so you're not allowed to modify them in-place. List a file here and the hardlink gets broken so you can modify it. This is a workaround, bestie โ€” ideally installing files should replace files, not modify existing ones. ๐Ÿฉน
  • only-arches (array of strings) โ€” if non-empty, only build the module on the arches listed.
  • skip-arches (array of strings) โ€” don't build on any of the arches listed.
  • cleanup-platform (array of strings) โ€” extra files to clean up in the platform.
  • run-tests (boolean) โ€” if true, this runs the tests after installing. ๐Ÿงช
  • test-rule (string) โ€” the target to build when running the tests. Defaults to "check" for make and "test" for ninja. Set it to empty to disable.
  • test-commands (array of strings) โ€” commands to run during the tests.
  • license-files (array of strings) โ€” paths to LICENSE files of the module. ๐Ÿ“œ
  • modules (array of objects or strings) โ€” an array of objects specifying nested modules to build before this one. String members in the array are interpreted as names of a separate json or yaml file containing a module. ๐Ÿช†

๐ŸŒˆ Sources

These hold a pointer to the source that gets extracted into the source directory before the build starts. They come in several types, told apart by the type property.

Also โ€” the sources list can contain a plain string, which is interpreted as the name of a separate json or yaml file that gets read and inserted right at that point โœจ. That file can hold a single source, or an array of sources.

๐ŸŒŸ All sources

  • only-arches (array of strings) โ€” if non-empty, only build the module on the arches listed.
  • skip-arches (array of strings) โ€” don't build on any of the arches listed.
  • dest (string) โ€” directory inside the source dir where this source gets extracted.

๐Ÿ—œ๏ธ Archive sources (tar, zip)

  • type โ€” must be "archive".
  • path (string) โ€” the path of the archive.
  • url (string) โ€” the URL of a remote archive that gets downloaded ๐ŸŒ. This overrides path if both are specified.
  • mirror-urls (array of strings) โ€” a list of alternative urls used if the main url fails. backups for your backups ๐Ÿ’–
  • referer (string) โ€” sets the HTTP "Referer" header when downloading the archive.
  • disable-http-decompression (boolean) โ€” disables decompression of downloads over HTTP, for those misconfigured servers. ๐Ÿ™ƒ
  • git-init (boolean) โ€” whether to initialise the repository as a git repository.
  • archive-type (string) โ€” the type of archive, in case it can't be guessed from the path. Possible values: "rpm", "tar", "tar-gzip", "tar-compress", "tar-bzip2", "tar-lzip", "tar-lzma", "tar-lzop", "tar-xz", "tar-zst", "zip" and "7z".
  • md5 (string) โ€” the md5 checksum of the file, verified after download. โœ…
okay bestie this next option is lowkey a jumpscare, read the note ๐Ÿ’€
  • md5 (string) โ€” the md5 checksum of the file, verified after download. This one's optional for local files.
fr fr, md5 is not considered a safe checksum anymore โ€” we recommend you use at least sha256. like, please. i'm begging. ๐Ÿ™
  • sha1 (string) โ€” the sha1 checksum of the file, verified after download. Also optional for local files.
and no, sha1 is not considered a safe checksum either โ€” recommend you use at least sha256. iykyk. ๐Ÿ’…
  • sha256 (string) โ€” the sha256 checksum of the file, verified after download. Optional for local files. this one is the safe bestie โœจ
  • sha512 (string) โ€” the sha512 checksum of the file, verified after download. Optional for local files. also iconic, also safe โœจ
  • strip-components (integer) โ€” how many initial pathname components get stripped during extraction. defaults to 1.
  • dest-filename (string) โ€” the filename for the downloaded file. defaults to the basename of url. ๐ŸŽ€

๐ŸŒˆ Git sources

  • type โ€” the string "git", that's it, that's the vibe.
  • path (string) โ€” the path to a local checkout of the git repository. because of how git-clone works, this is gonna be so much faster than handing it a URL of file:///.... no cap.
  • url (string) โ€” the URL of the git repository. this one overrides path if you specify both, so like, pick one. and when you're using git over SSH, the correct syntax is ssh://user@domain/path/to/repo.git. don't freestyle it.
  • branch (string) โ€” the branch to use from the git repository. as of 1.2.3 it'll try to auto-detect the upstream default branch. previously this defaulted to master. ๐Ÿ‘‘
  • tag (string) โ€” the tag to use from the git repository.
  • commit (string) โ€” the commit to use from the git repository. if branch is also specified, then it gets verified that the branch/tag is at this specific commit. it's a readable way to document that you're using a particular tag, but also verify that it doesn't change. chef's kiss security move ๐Ÿซถ
  • disable-fsckobjects (boolean) โ€” don't use transfer.fsckObjects=1 to mirror the git repository. this may be needed for some (broken) repositories. ๐Ÿ˜ญ
  • disable-shallow-clone (boolean) โ€” don't optimize by making a shallow clone when downloading the git repo.
  • disable-submodules (boolean) โ€” don't checkout the git submodules when cloning the repository.
  • disable-lfs (boolean) โ€” don't explicitly fetch or checkout LFS git objects. this will be ignored by Git if LFS filters are active in system or global gitconfig.

๐Ÿ“ Bzr sources

  • type โ€” the string "bzr".
  • url (string) โ€” URL of the bzr repository.
  • revision (string) โ€” a specific revision to use in the branch.

๐Ÿงš Svn sources

  • type โ€” the string "svn".
  • url (string) โ€” URL of the svn repository, including the branch/tag part.
  • revision (string) โ€” a specific revision number to use.

๐Ÿฆ‹ Directory sources

  • type โ€” the string "dir".
  • path (string) โ€” the path of a local directory whose content will be copied into the source dir.
heads up: directory sources don't currently support caching, so they'll be rebuilt each time. every. single. time. ๐Ÿ˜ฎโ€๐Ÿ’จ
  • skip (array of strings) โ€” source files to ignore in the directory.

๐Ÿ’œ File sources

  • type โ€” the string "file".
  • path (string) โ€” the path of a local file that will be copied into the source dir.
  • url (string) โ€” the URL of a remote file that will be downloaded and copied into the source dir. this overrides path if both are specified.
  • mirror-urls (array of strings) โ€” a list of alternative urls that are used if the main url fails. backup besties fr. ๐Ÿซถ
  • referer (string) โ€” sets the HTTP "Referer" header when downloading the file.
  • disable-http-decompression (boolean) โ€” disables decompression of downloads over HTTP for misconfigured servers. (misconfigured server behavior, not yours, not your fault)
  • md5 (string) โ€” the md5 checksum of the file, verified after download. this is optional for local files.
md5 is no longer considered a safe checksum โ€” we recommend you use at least sha256.
  • sha1 (string) โ€” the sha1 checksum of the file, verified after download. optional for local files.
same deal, sha1 is no longer considered a safe checksum โ€” use at least sha256. periodt.
  • sha256 (string) โ€” the sha256 checksum of the file, verified after download. that's optional for local files. ๐Ÿ’–
  • sha512 (string) โ€” the sha512 checksum of the file, verified after download. also optional for local files. ๐Ÿ’–
  • dest-filename (string) โ€” the filename to use inside the source dir, defaults to the basename of path. ๐ŸŽ€

โญ Script sources

this is a way to create a shell (/bin/sh) script out of an inline set of commands. cute, right?

  • type โ€” the string "script".
  • commands (array of strings) โ€” an array of shell commands that will be put in a shellscript file.
  • dest-filename (string) โ€” the filename to use inside the source dir, defaults to autogen.sh. yes, that autogen.sh. ๐Ÿ˜ญ

๐ŸŒธ Inline data sources

this is a way to create a file with given contents. main character energy for tiny files โœจ

  • type โ€” the string "inline".
  • dest-filename (string) โ€” the filename to use inside the source dir.
  • contents (string) โ€” text data that will be put in the file.
  • base64 (boolean) โ€” whether the content is base64-encoded.

๐Ÿ’… Shell sources

this is a way to create/modify the sources by running shell commands.

  • type โ€” the string "shell".
  • commands (array of strings) โ€” an array of shell commands that will be run during source extraction.

๐ŸŽ€ Patch sources

  • type โ€” the string "patch".
  • path (string) โ€” the path of a patch file that will be applied in the source dir.
  • paths (array of strings) โ€” a list of paths to patch files that will be applied in the source dir, in order. (yes, the original says "an list". we don't judge, we just apply patches in order ๐Ÿ’–)
  • strip-components (integer) โ€” the value of the -p argument to patch, defaults to 1.
  • use-git (boolean) โ€” whether to use git apply rather than patch to apply the patch. required when the patch file contains binary diffs.
  • use-git-am (boolean) โ€” whether to use git am rather than patch to apply the patch. required when the patch file contains binary diffs.
you cannot use this at the same time as use-git. pick a lane bestie ๐Ÿ˜ค
  • options (array of strings) โ€” extra options to pass to the patch command.

๐Ÿ”ฅ Extra data sources

  • type โ€” the string "extra-data".
  • filename (string) โ€” the name to use for the downloaded extra data.
  • url (string) โ€” the url to the extra data.
  • sha256 (string) โ€” the sha256 of the extra data.
  • size (number) โ€” the size of the extra data in bytes.
  • installed-size (string) โ€” the extra installed size this adds to the app. optional. ๐Ÿ’œ

๐Ÿ”จ BUILD ENVIRONMENT ๐Ÿ”จ

okay so when building the application, each command gets run in a separate sandbox with access to only the things it actually requires. this section describes the details of that sandbox. any options here can be overridden globally or per-module with the build-args option โ€” although, plot twist, such a manifest will not work if you start flatpak-builder with --sandbox. ๐Ÿ˜ฌ

๐Ÿ“ Filesystem

each module is built in its own build directory, stored in a sub directory called build/$modulename-$count in the state dir (which is typically .flatpak-builder/). additionally there's a symlink build/$modulename pointing to the latest version. ๐Ÿ‘‘

and in order to generate reproducible builds, this directory is also mounted as /run/build/$modulename in the sandbox (or /run/build-runtime/$modulename when building runtimes) and also as /run/active-build since 1.4.7. this is used as the current working directory for all build ops.

the destination directory for installation is accessible for writing at the place it'll be seen at runtime. in the case of a regular application this will be /app. if you're building a runtime it'll instead be /usr, and when building an extension it'll be at the extensionpoint directory somewhere below /app (for app extension) or /usr (for runtime extensions).

additionally there will be (as needed, depending on what's building) read-only mounts of the sdk at /usr, sdk extensions below that, and the application at /app. no other filesystem access is available. that's the whole world. ๐ŸŒ

๐ŸŒˆ Environment

the environment can be modified in several ways in the manifest, but the default values are:

  • FLATPAK_ID โ€” the id of the application currently building.
  • FLATPAK_ARCH โ€” the architecture currently building.
  • FLATPAK_DEST โ€” the path to where the current build should install into. this is /app for application builds.
  • FLATPAK_BUILDER_N_JOBS โ€” the number of jobs that flatpak-builder would normally use for make -j. defaults to ncpus unless the module disabled parallel make.
  • FLATPAK_BUILDER_BUILDDIR โ€” the path to the build directory of the module currently building. this is normally /run/build/$MODULE.
  • PATH โ€” /app/bin:/usr/bin
  • LD_LIBRARY_PATH โ€” /app/lib
  • PKG_CONFIG_PATH โ€” /app/lib/pkgconfig:/app/share/pkgconfig:/usr/lib/pkgconfig:/usr/share/pkgconfig
  • ACLOCAL_PATH โ€” /app/share/aclocal
  • C_INCLUDE_PATH โ€” /app/include
  • CPLUS_INCLUDE_PATH โ€” /app/include
  • LDFLAGS โ€” -L/app/lib
  • LC_ALL โ€” en_US.utf8

๐Ÿ” Permissions

builds have the --allow=devel and --allow=multiarch permissions that regular flatpak runs don't have by default. this limits the syscall filtering that's normally done so development tools like debuggers actually work. otherwise the build sandbox is very limited โ€” for example, there is no network access. offline era fr. ๐Ÿ“ต

โœจ EXAMPLES โœจ

okay bestie, time for the part you've been waiting for โ€” actual receipts ๐Ÿ’… here's the whole vibe in action:

$ flatpak-builder my-app-dir manifest.json

that's it. that's the whole command. you point it at your app dir and your manifest and it goes ๐Ÿƒโ€โ™€๏ธ๐Ÿ’จ


and here's what an example manifest file looks like, in all its glory, no cap:

{
    "id": "org.test.TestApp",
    "runtime": "org.freedesktop.Platform",
    "runtime-version": "1.2",
    "sdk": "org.freedesktop.Sdk",
    "command": "test",
    "clean": [ "/include", "*.la" ],
    "build-options" : {
        "cflags": "-O2 -g",
        "cxxflags": "-O2 -g",
        "env": {
            "V": "1"
        },
        "arch": {
            "x86_64": {
                "cflags": "-O3 -g",
            }
        }
    },
    "modules": [
        {
            "name": "pygobject",
            "config-opts": [ "--disable-introspection" ],
            "sources": [
                {
                    "type": "archive",
                    "url": "http://ftp.gnome.org/pub/GNOME/sources/pygobject/2.28/pygobject-2.28.6.tar.xz",
                    "sha256": "fb8a1d4f665130a125011659bd347c7339c944232163dbb9a34fd0686577adb8"
                },
                {
                    "type": "patch",
                    "path": "required-pygobject-fix.patch"
                },
                {
                    "type": "file",
                    "path": "pygobject-extra-file",
                    "dest-filename": "extra-file"
                }
            ]
        },
        {
            "name": "babl",
            "build-options" : { "cxxflags": "-O2 -g -std=c++11" },
            "cleanup": [ "/bin" ],
            "sources": [
                {
                    "type": "git",
                    "url": "https://gitlab.gnome.org/GNOME/babl.git"
                }
            ]
        },
        {
            "name": "testapp",
            "sources": [
                {
                    "type": "bzr",
                    "url": "lp:testapp"
                }
            ]
        }
    ]
}

look at that structure. chef's kiss ๐ŸคŒ three modules, three whole different source types living their best lives โ€” an archive with its sha256, a patch, a file, then a git source, then a bzr source. and the global clean list, the per-module cleanup, the build-options with cflags, cxxflags, env and even a per-arch override for x86_64. every single field is out here doing its job ๐ŸŽ€

ngl bestie, do NOT copy the trailing commas โ€” the original shows them and they're giving "technically invalid JSON" energy. write clean JSON in your real manifest, k? ๐Ÿ’€

๐Ÿ‘€ SEE ALSO ๐Ÿ‘€

  • flatpak-builder(1) โ€” the main character. go read it, it's literally the thing that eats this manifest for breakfast ๐Ÿ“

okay and that's a wrap on the whole page, bestie! ๐Ÿซถ you made it through all of it, and honestly? iconic behavior. go build something cute.

this page comes to you courtesy of flatpak, and it lives under the name FLATPAK MANIFEST(5) โ€” so if you ever need to find it again, that's your search term โœจ happy building, go slay ๐Ÿ’–๐ŸŒธ

๐Ÿ“ฆ where this page comes from