FLATPAK-BUILD(1)

πŸ’… FLATPAK-BUILD β€” the flatpak build page, but make it make sense

okay bestie, welcome to the flatpak build(1) manual, section 1 of the flatpak manual. this is the one that actually runs your build command inside a directory. let's go πŸŽ€


✨ NAME ✨

flatpak-build β€” build in a directory. that's it. that's the whole name. short, sweet, iconic. πŸ‘‘


πŸ¦‹ SYNOPSIS πŸ¦‹

flatpak build [OPTION...] DIRECTORY [COMMAND [ARG...]]

🌸 DESCRIPTION 🌸

so what this does: it runs a build command in a directory. no cap.

and like, DIRECTORY has to have been initialized first with flatpak build-init. you can't just roll up with a random folder, she needs to be prepped. πŸ™ˆ

here's the cute part, the actual magic: the sdk that's specified in the metadata file inside that directory gets mounted at /usr. and then the files and var subdirectories get mounted at /app and /var, respectively. πŸ’«

and the way they're writable, and their contents are preserved between build commands? that's the whole point, bestie β€” it lets you accumulate build artifacts in there. your progress stays. she remembers. 🫢


πŸ’– OPTIONS πŸ’–

here's everything you can pass. the following options are understood:

  • -h, --help β€” show help options and dip. exit, periodt. ✌️
  • -v, --verbose β€” print debug information while the command is processing. she's chatty and we love that.
  • --ostree-verbose β€” print OSTree debug information during command processing. yes, more. give us more. πŸ”₯
  • -r, --runtime β€” use the non-devel runtime that's specified in the application metadata instead of the devel runtime. glow-down mode, but make it intentional.
  • -p, --die-with-parent β€” kill the build process and all its children when the launching process dies. dramatic? yes. necessary? also yes. πŸ’€
  • --bind-mount=DEST=SOURCE β€” add a custom bind mount in the build namespace. can be specified multiple times. stack 'em up. 🧚
  • --build-dir=PATH β€” start the build in this directory (the default is in the current directory).
  • --share=SUBSYSTEM β€” share a subsystem with the host session. this overrides the Context section from the application metadata. SUBSYSTEM must be one of: network, ipc. this option can be used multiple times. sharing is caring fr fr.
  • --unshare=SUBSYSTEM β€” don't share a subsystem with the host session. this overrides the Context section from the application metadata. SUBSYSTEM must be one of: network, ipc. this option can be used multiple times. boundaries. we set them. 🚧
  • --socket=SOCKET β€” expose a well-known socket to the application. this overrides to the Context section from the application metadata. SOCKET must be one of: x11, wayland, fallback-x11, pulseaudio, system-bus, session-bus, ssh-auth, pcsc, cups, gpg-agent, inherit-wayland-socket. this option can be used multiple times.
  • --nosocket=SOCKET β€” don't expose a well-known socket to the application. this overrides to the Context section from the application metadata. SOCKET must be one of: x11, wayland, fallback-x11, pulseaudio, system-bus, session-bus, ssh-auth, pcsc, cups, gpg-agent, inherit-wayland-socket. this option can be used multiple times.
  • --device=DEVICE β€” expose a device to the application. this overrides to the Context section from the application metadata. DEVICE must be one of: dri, input, usb, kvm, shm, all. this option can be used multiple times.
  • --nodevice=DEVICE β€” don't expose a device to the application. this overrides to the Context section from the application metadata. DEVICE must be one of: dri, input, usb, kvm, shm, all. this option can be used multiple times.
  • --allow=FEATURE β€” allow access to a specific feature. this updates the [Context] group in the metadata. FEATURE must be one of: devel, multiarch, bluetooth, canbus, per-app-dev-shm. this option can be used multiple times.

see flatpak-build-finish(1) for the meaning of the various features. πŸ‘€

  • --disallow=FEATURE β€” disallow access to a specific feature. this updates the [Context] group in the metadata. FEATURE must be one of: devel, multiarch, bluetooth, canbus, per-app-dev-shm. this option can be used multiple times.
  • --filesystem=FILESYSTEM[:ro|:create] β€” allow the application access to a subset of the filesystem. this overrides to the Context section from the application metadata. FILESYSTEM can be one of: home, host, host-os, host-etc, host-root, xdg-desktop, xdg-documents, xdg-download, xdg-music, xdg-pictures, xdg-public-share, xdg-templates, xdg-videos, xdg-run, xdg-config, xdg-cache, xdg-data, an absolute path, or a homedir-relative path like ~/dir or paths relative to the xdg dirs, like xdg-download/subdir. the optional :ro suffix indicates that the location will be read-only. the optional :create suffix indicates that the location will be read-write and created if it doesn't exist. this option can be used multiple times. see the "[Context] filesystems" list in flatpak-metadata(5) for details of the meanings of these filesystems.
ok important lore: before flatpak 1.17.0, access to host was granted by default. she used to be that generous. πŸ™ˆ
  • --nofilesystem=FILESYSTEM β€” remove access to the specified subset of the filesystem from the application. this overrides to the Context section from the application metadata. FILESYSTEM can be one of: home, host, host-os, host-etc, host-root xdg-desktop, xdg-documents, xdg-download, xdg-music, xdg-pictures, xdg-public-share, xdg-templates, xdg-videos, an absolute path, or a homedir-relative path like ~/dir. this option can be used multiple times.
  • --with-appdir β€” expose and configure access to the per-app storage directory in $HOME/.var/app. this is not normally useful when building, but it helps when testing built apps. so like, not for the build build, but for the after. πŸ§ͺ
  • --add-policy=SUBSYSTEM.KEY=VALUE β€” add generic policy option. for example, "--add-policy=subsystem.key=v1 --add-policy=subsystem.key=v2" would map to this metadata:
[Policy subsystem]
key=v1;v2;

this option can be used multiple times.

  • --remove-policy=SUBSYSTEM.KEY=VALUE β€” remove generic policy option. this option can be used multiple times. bye bye policy. πŸ’…
  • --env=VAR=VALUE β€” set an environment variable in the application. this overrides to the Context section from the application metadata. this option can be used multiple times.
  • --unset-env=VAR β€” unset an environment variable in the application. this overrides the unset-environment entry in the [Context] group of the metadata, and the [Environment] group. this option can be used multiple times.
  • --env-fd=FD β€” read environment variables from the file descriptor FD, and set them as if via --env. this can be used to avoid environment variables and their values becoming visible to other users. πŸ”’

each environment variable is in the form VAR=VALUE followed by a zero byte. this is the same format used by env -0 and /proc/*/environ.

  • --own-name=NAME β€” allow the application to own the well-known name NAME on the session bus. this overrides to the Context section from the application metadata. this option can be used multiple times. main character energy, she owns the name literally. πŸ‘‘
  • --talk-name=NAME β€” allow the application to talk to the well-known name NAME on the session bus. this overrides to the Context section from the application metadata. this option can be used multiple times.
  • --system-own-name=NAME β€” allow the application to own the well-known name NAME on the system bus. this overrides to the Context section from the application metadata. this option can be used multiple times.
  • --system-talk-name=NAME β€” allow the application to talk to the well-known name NAME on the system bus. this overrides to the Context section from the application metadata. this option can be used multiple times.
  • --persist=FILENAME β€” if the application doesn't have access to the real homedir, make the (homedir-relative) path FILENAME a bind mount to the corresponding path in the per-application directory, allowing that location to be used for persistent data. this overrides to the Context section from the application metadata. this option can be used multiple times. it persists. like the group chat. πŸ’œ
  • --sdk-dir=DIR β€” normally, if there's a usr directory in the build dir, this is used for the runtime files (this can be created by --writable-sdk or --type=runtime arguments to build-init). if you specify --sdk-dir, this directory will be used instead. use this if you passed --sdk-dir to build-init. matching sets, bestie. πŸŽ€
  • --readonly β€” mount the normally writable destination directories read-only. this can be useful if you want to run something in the sandbox but guarantee that it doesn't affect the build results. for example tests. πŸ§ͺ✨
  • --metadata=FILE β€” use the specified filename as metadata in the exported app instead of the default file (called metadata). this is useful if you build multiple things from a single build tree (such as both a platform and a sdk). multi-tasking queen. 🌈
  • --log-session-bus β€” log session bus traffic. this can be useful to see what access you need to allow in your D-Bus policy.
  • --log-system-bus β€” log system bus traffic. this can be useful to see what access you need to allow in your D-Bus policy.

πŸ”₯ EXAMPLES πŸ”₯

$ flatpak build /build/my-app rpmbuild my-app.src.rpm

that's the whole example and honestly? it ate. πŸ“


πŸ¦‹ SEE ALSO πŸ¦‹

flatpak(1), flatpak-build-init(1), flatpak-build-finish(1), flatpak-build-export(1)


okay that's the page!! this came from the flatpak manual, page FLATPAK BUILD(1), and that footer energy is all hers πŸ’– go build something gorgeous bestie, ily, no cap ✨🫢

πŸ“¦ where this page comes from