FLATPAK-METADATA(5)

📦
version 1.18.4 · 17 versions
, in fedora 44, nixpkgs unstable, ubuntu stonking

FLATPAK METADATA(5) — flatpak metadata 💖

okay bestie, buckle up, this is the flatpak-metadata page and it's lowkey a whole vibe. it's section 5 of the flatpak manual, and it's all about the little .ini files that tell Flatpak what an app or runtime even is. ✨

🌸 NAME 🌸

flatpak-metadata — all the tea about an application or runtime 🫖

💅 DESCRIPTION 💅

so. Flatpak uses metadata files to describe applications and runtimes. iconic behavior honestly. the metadata file for a deployed application or runtime lives in the toplevel deploy directory. for example, the metadata for the locally installed application org.gnome.Calculator is chilling at:

~/.local/share/flatpak/app/org.gnome.Calculator/current/active/metadata

most aspects of the metadata configuration can be overridden when launching applications, either:

  • temporarily, via options of the flatpak run command, or
  • permanently, with the flatpak override command. 👑

a metadata file describing the effective configuration is available inside the running sandbox at /.flatpak-info. and for compatibility with older Flatpak versions, /run/user/$UID/flatpak-info is a symbolic link to that same file. no cap, it's the same file. 🔗

🦋 FILE FORMAT 🦋

the metadata file uses the same .ini file format as systemd unit files or application .desktop files. you already know this format, bestie, you've got this. 💪

🌟 [Application] or [Runtime] 🌟

metadata for applications starts with an [Application] group, and metadata for runtimes starts with a [Runtime] group. pick your fighter. 🥊

the following keys can be present in these groups:

  • name (string) — the name of the application or runtime. this key is mandatory, fr fr.
  • runtime (string) — the fully qualified name of the runtime that the application uses. this key is mandatory for applications.
  • sdk (string) — the fully qualified name of the sdk that matches the runtime. available since 0.1.
  • command (string) — the command to run. only relevant for applications. available since 0.1.
  • required-flatpak (string list) — the required version of Flatpak to run this application or runtime. for applications, this was available since 0.8.0. for runtimes, this was available since 0.9.1, and backported to 0.8.3 for the 0.8.x branch. Flatpak after version 1.4.3 and 1.2.5 support multiple versions here. this is useful if you need to support features that got backported to a previous stable series. for example, if you wanna use a feature added in 1.6.0 that was also backported to 1.4.4, you'd write 1.6.0;1.4.4;. note that older versions of flatpak will just use the first element in the list, so make that one the largest version. 💀 (iykyk)
  • tags (string list) — tags to include in AppStream XML. typical values in use on Flathub include beta, stable, proprietary and upstream-maintained. available since 0.4.12. 🏷️

🎀 [Context] 🎀

this group determines the various system resources that may be shared with the application when it's run in a flatpak sandbox. it's giving "what are we letting the app touch" energy.

✨ Conditional Permissions ✨

some permissions (such as sockets and devices) support conditional grants, where access is only provided when specific runtime conditions are met. this lets applications adapt to different system capabilities and session types. available since 1.17. 🌈

conditional permissions use the syntax if:PERMISSION:CONDITION in the metadata file. for example, if:wayland:has-wayland grants Wayland socket access only when running in a Wayland session.

the following conditions are supported:

  • true — always evaluates to true. ✅
  • false — always evaluates to false. ❌
  • has-input-device — true if this version of Flatpak supports the input device permission. this is always true in Flatpak 1.15.6 and later, and can be used to provide fallback behavior for older Flatpak versions.
  • has-wayland — true if the current desktop session supports Wayland.
  • has-usb-device — true if this version of Flatpak supports the usb device permission. this is always true in Flatpak 1.16.0 and later, and can be used to provide fallback behavior for older Flatpak versions.
  • has-usb-portal — true if the current desktop session supports the USB Portal.

conditions can be negated by prefixing with !. for example, if:x11:!has-wayland grants X11 socket access only when NOT running in a Wayland session. 🙈

multiple conditional permissions can be specified for the same resource. if any condition matches, the permission is granted (OR logic). for example:

sockets=wayland;if:x11:!has-wayland;if:x11:false

for backward compatibility with older Flatpak versions, conditional permissions can be combined with unconditional grants:

sockets=x11;if:x11:!has-wayland;

older Flatpak versions will grant X11 access unconditionally (seeing only x11), while newer versions recognize the conditional syntax and grant X11 access only when not in Wayland sessions. bestie, it's a whole time-travel trick. ⏳

to explicitly deny a permission that might be granted at a lower layer (such as from the runtime or a global override), prefix the permission name with !:

sockets=!x11;

this denial can be combined with conditional grants to remove unconditional access while allowing conditional access:

sockets=!x11;x11;if:x11:!has-wayland;

this denies unconditional X11 access, but allows X11 access conditionally when not running in a Wayland session. the seemingly contradictory !x11 and x11 ensures backward compatibility: older Flatpak versions see the final x11 grant, while newer versions understand the conditional logic. 🤯

all keys in this group (and the group itself) are optional. breathe easy. 🫶

the keys supported in this group are:

  • shared (list) — list of subsystems to share with the host system. possible subsystems: network, ipc. available since 0.3. this option supports conditional permissions. see Conditional Permissions for details on how to share subsystem access conditionally based on runtime conditions.
  • sockets (list) — list of well-known sockets to make available in the sandbox. possible sockets: x11, wayland, fallback-x11, pulseaudio, session-bus, system-bus, ssh-auth, pcsc, cups, gpg-agent, inherit-wayland-socket. when making a socket available, flatpak also sets well-known environment variables like DISPLAY or DBUS_SYSTEM_BUS_ADDRESS so the application can find sockets that aren't in a fixed location. available since 0.3. this option supports conditional permissions. see Conditional Permissions for details on how to grant socket access conditionally based on runtime conditions.
  • devices (list) — list of devices to make available in the sandbox. this just exposes the device nodes, it doesn't grant any permission that the user doesn't already have. possible values:
    • dri — GPU graphics and compute (/dev/dri), including vendor specific render and compute devices. available since 0.3.
    • input — input devices (/dev/input). available since 1.15.6.
    • usb — USB device bus (all device nodes below /dev/bus/usb). available since 1.15.11.
    • kvm — virtualization (/dev/kvm). available since 0.6.12.
    • all — all device nodes in /dev, but not /dev/shm (which is separately specified). available since 0.6.6.
    • shm — access to the host /dev/shm (/dev/shm). available since 1.6.1. this option supports conditional permissions. see Conditional Permissions for details on how to grant device access conditionally based on runtime conditions.
  • filesystems (list) — list of filesystem subsets to make available to the application. possible values:
    • home — the entire home directory. available since 0.3.
    • home/path — alias for ~/path. available since 1.10. for better compatibility with older Flatpak versions, prefer to write this as ~/path. 🙏
    • host — the entire host file system, except for directories that are handled specially by Flatpak. in particular, this shares /home, /media, /opt, /run/media and /srv if they exist. /dev is not shared: use devices=all; instead. parts of /sys are always shared. this option does not make additional files in /sys available. additionally, this keyword provides all of the same directories in /run/host as the host-os and host-etc keywords. if this keyword is used in conjunction with one of the host- keywords, whichever access level is higher (more permissive) will be used for the directories in /run/host: for example, host:rw;host-os:ro; is equivalent to host:rw;. these other reserved directories are currently excluded: /app, /bin, /boot, /efi, /etc, /lib, /lib32, /lib64, /proc, /root, /run, /sbin, /tmp, /usr, /var. available since 0.3.
    • host-os — the host operating system's libraries, executables and static data from /usr and the related directories /bin, /lib, /lib32, /lib64, /sbin. additionally, this keyword provides access to a subset of /etc that is associated with packaged libraries and executables, even if the host-etc keyword was not used: /etc/ld.so.cache, (used by the dynamic linker) and /etc/alternatives (on operating systems that use it, such as Debian). to avoid conflicting with the Flatpak runtime, these are mounted in the sandbox at /run/host/usr, /run/host/etc/ld.so.cache and so on. available since 1.7.
    • host-etc — the host operating system's configuration from /etc. to avoid conflicting with the Flatpak runtime, this is mounted in the sandbox at /run/host/etc. available since 1.7.
    • host-root — the complete host operating system. to avoid conflicting with the Flatpak runtime, this is mounted in the sandbox at /run/host/root.
this permission is only intended to be used as a last resort when there is no possible alternative with other filesystem permissions for applications that need the entire root filesystem of the host. ⚠️

please note that following symlinks under /run/host/root naively will result in a wrong path. for example, using realpath() is wrong. instead, applications will have to implement some way of following symlinks in a way that behaves as if it were chroot'd into /run/host/root. 😭 no shortcuts bestie, sorry.

There are a few ways to do this. Modern kernels support the openat2()[1] call with RESOLVE_IN_ROOT. For a more portable solution with support for older kernels, see the implementation from the steam-runtime-tools[2] as an example.

Available since 1.17.

  • xdg-desktop, xdg-documents, xdg-download, xdg-music, xdg-pictures, xdg-public-share, xdg-videos, xdg-templates — the freedesktop.org special directories[3]. Available since 0.3.
  • xdg-desktop/path, xdg-documents/path, etc. — subdirectories inside those freedesktop.org special directories. Available since 0.4.13.
  • xdg-cache, xdg-config, xdg-data — the directories defined by the freedesktop.org Base Directory Specification[4]. Available since 0.6.14.
  • xdg-cache/path, xdg-config/path, xdg-data/path — subdirectories of the directories defined by the freedesktop.org Base Directory Specification. Available since 0.6.14.
  • xdg-run/path — subdirectories of the XDG_RUNTIME_DIR defined by the freedesktop.org Base Directory Specification. Heads up tho: xdg-run all on its own is not supported, bestie. Available since 0.4.13.
  • /path — any absolute path you want, just raw like that. Available since 0.3.
  • ~/path — any path relative to the home directory. Available since 0.3.
  • ~ — same thing as home. Available since 1.10. For better compatibility with older Flatpak versions, prefer to write this as home.
  • one of the above, followed by :ro — makes that directory available read-only.
  • one of the above, followed by :rw — makes that directory available read/write. This is the default, so if you say nothing, this is what you get.
  • one of the above, followed by :create — makes that directory available read/write, and creates it if it doesn't already exist.
  • persistent (list) — a list of homedir-relative paths to make available at the corresponding path in the per-application home directory, so those spots can be used for persistent data when the app doesn't have access to the real homedir. Like, say you make ".myapp" persistent — then "~/.myapp" inside the sandbox becomes a bind mount to "~/.var/app/org.my.App/.myapp", which means an unmodified application can save its data in the per-application location. Available since 0.3.
  • features (list) — a list of features that are available or unavailable to the application, currently from this list right here:
    • devel — allows the system calls used by development-oriented tools like perf, strace and gdb. Available since 0.6.10.
    • multiarch — allows running multilib/multiarch binaries, for example i386 binaries in an x86_64 environment. Available since 0.6.12.
    • bluetooth — allows the application to use bluetooth (AF_BLUETOOTH) sockets. Note tho: for bluetooth to fully work you also gotta have network access. Available since 0.11.8.
    • canbus — allows the application to use canbus (AF_CAN) sockets. Note that for this to work you also gotta have network access. Available since 1.0.3.
    • per-app-dev-shm — shares a single instance of /dev/shm between all instances of this application run by the same user ID, including sub-sandboxes. If the application has the shm device permission in its devices list, then this feature flag is just ignored. Available since 1.12.0.

A feature can be prefixed with ! to indicate the absence of that feature — for example !devel if development and debugging are not allowed. Iconic negation moment.

This option supports conditional permissions. See Conditional Permissions for the deets on how to allow features conditionally, based on runtime conditions.

  • unset-environment (list) — a list of names of environment variables to unset. Note that environment variables you want to set to a value (even an empty one) live over in the [Environment] group instead. Different group, different job.

🫶 [Instance] 🫶

This group only shows up in /.flatpak-info for a running app, and not in the metadata files written by application authors. Flatpak itself fills it in. It's like the app's little ID card, no cap.

  • instance-id (string) — the ID of the running instance. This number is used as the name of the directory in XDG_RUNTIME_DIR/.flatpak where Flatpak stores information about this instance.
  • instance-path (string) — the absolute path on the host system of the app's persistent storage area in $HOME/.var.
  • app-path (string) — the absolute path on the host system of the app's app files, as mounted at /app inside the container. Available since 0.6.10.

Since 1.12.0, if flatpak run was run with the --app-path option, this key gives the absolute path of whatever files were mounted on /app, even if that differs from the app's normal app files.

If flatpak run was run with --app-path= (which results in an empty directory being mounted on /app), the value is set to the empty string. Yes, empty. On purpose.

  • original-app-path (string) — if flatpak run was run with the --app-path option, this key gives the absolute path of the app's original files, as mounted at /run/parent/app inside the container. Available since 1.12.0.

If this key is missing, the app files are given by app-path.

  • app-commit (string) — the commit ID of the application that is running. The filename of a deployment of this commit can be found in original-app-path if present, or app-path otherwise.
  • app-extensions (list of strings) — a list of app extensions that are mounted into the running instance. The format for each list item is EXTENSION_ID=COMMIT. If original-app-path is present, the extensions are mounted below /run/parent/app; otherwise, they are mounted below /app.
  • branch (string) — the branch of the app, for example stable. Available since 0.6.10.
  • arch (string) — the architecture of the running instance.
  • flatpak-version (string) — the version number of the Flatpak version that ran this app. Available since 0.6.11.
  • runtime-path (string) — the absolute path on the host system of the app's runtime files, as mounted at /usr inside the container. Available since 0.6.10.

Since 1.12.0, if flatpak run was run with the --usr-path option, this key gives the absolute path of whatever files were mounted on /usr, even if that differs from the app's normal runtime files.

  • original-runtime-path (string) — if flatpak run was run with the --runtime-path option, this key gives the absolute path of the app's original runtime, as mounted at /run/parent/usr inside the container. Available since 1.12.0.

If this key is missing, the runtime files are given by runtime-path.

  • runtime-commit (string) — the commit ID of the runtime that is used. The filename of a deployment of this commit can be found in original-runtime-path if present, or runtime-path otherwise.
  • runtime-extensions (list of strings) — a list of runtime extensions that are mounted into the running instance. The format for each list item is EXTENSION_ID=COMMIT. If original-app-path is present, the extensions are mounted below /run/parent/usr; otherwise, they are mounted below /usr.
  • extra-args (string) — extra arguments that were passed to flatpak run.
  • sandbox (boolean) — whether the --sandbox option was passed to flatpak run.
  • build (boolean) — whether this instance was created by flatpak build.
  • session-bus-proxy (boolean) — true if this app cannot access the D-Bus session bus directly (either it goes via a proxy, or it can't access the session bus at all). Available since 0.8.0.
  • system-bus-proxy (boolean) — true if this app cannot access the D-Bus system bus directly (either it goes via a proxy, or it can't access the system bus at all). Available since 0.8.0.

🌈 [Session Bus Policy] 🌈

If the sockets key is not allowing full access to the D-Bus session bus, then flatpak provides filtered access instead. It's giving bouncer energy, honestly.

The default policy for the session bus only lets the application own its own application ID, its subnames, and its own application ID as a subname of org.mpris.MediaPlayer2. So for instance, if the app is called org.my.App, it can only own org.my.App, org.my.App.* and org.mpris.MediaPlayer2.org.my.App. It's only allowed to talk to names matching those patterns, plus the bus itself (org.freedesktop.DBus) and the portal APIs (bus names of the form org.freedesktop.portal.*).

Additionally, the app is always allowed to reply to messages sent to it, and emit broadcast signals (but these will not reach other sandboxed apps unless they are allowed to talk to your app.

If the [Session Bus Policy] group is present, it provides policy for session bus access.

Each key in this group has the form of a D-Bus bus name or a prefix thereof, for example org.gnome.SessionManager or org.freedesktop.portal.*.

The possible values for an entry are the following, in increasing order of access. Each value implies all the access from any lower values — so it stacks, bestie:

  • none — the bus name is invisible to the application. Available since 0.2.
  • see — the bus name can be enumerated by the application. Available since 0.2.
  • talk — the application can send messages to, and receive replies and signals from, the bus name. Available since 0.2.
  • own — the application can own the bus name. Available since 0.2.

🦋 [System Bus Policy] 🦋

If the sockets key is not allowing full access to the D-Bus system bus, then flatpak does not make the system bus available unless the [System Bus Policy] group is present and provides a policy for filtered access. Available since 0.2.

Entries in this group have the same form as for the [Session Bus Policy] group. However, the app has no permissions by default. Starting from zero, literally.

🎀 [Environment] 🎀

The [Environment] group specifies environment variables to set when running the application. Available since 0.3.

Entries in this group have the form VAR=VALUE where VAR is the name of an environment variable to set.

Note that environment variables can also be unset (removed from the environment) by listing them in the unset-environment entry of the [Context] group. Two ways to handle env vars, pick your fighter.

[Extension NAME] 🫶✨

Okay bestie, listen. Runtimes and apps can define extension points. These let optional extra runtimes get mounted at a specific spot inside the sandbox when they're actually present on the system. Think translations for apps, or debuginfo for sdks. The extension point name lives right in the group heading. Since 0.11.4, the NAME can optionally have a tag using the name@tag ref syntax — that's for when you want different configurations (like versions) of the same extension at the same time. The "tag" is basically ignored, but it's necessary so you can specify the same extension name more than once. 💅

  • directory (string) — The relative path where the extension gets mounted in the sandbox. If the extension point is for an app, the path is relative to /app; otherwise it's relative to /usr. This key is mandatory. Available since 0.1. 🎀
  • version (string) — The branch to use when looking for the extension. If you don't specify it, it defaults to the branch of the app or runtime that the extension point is for. Available since 0.4.1. 🌸
  • versions (string) — The branches to use when looking for the extension. If not specified, defaults to the branch of the app or runtime the extension point is for. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.4. 💖
  • add-ld-path (string) — A path relative to the extension point directory that gets appended to LD_LIBRARY_PATH. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.3. ✨
  • merge-dirs (string) — A list of relative paths of directories below the extension point directory that will be merged. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.3. 🦋
  • download-if (string) — A condition that must be true for the extension to be auto-downloaded. As of 1.1.1, this supports multiple conditions separated by semi-colons. 😌

These are the supported conditions:

  • active-gl-driver — True if the name of the active GL driver matches the extension point basename. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.3. 🔥
  • active-gtk-theme — True if the name of the current GTK theme (via org.gnome.desktop.interface GSetting) matches the extension point basename. Added 0.10.1. 🎨
  • have-intel-gpu — True if the i915 kernel module is loaded. Added 0.10.1. 💻
  • have-kernel-module-* — True if the suffix (case-sensitive) is found in /proc/modules. For example have-kernel-module-nvidia. Added 1.13.1. 🧠
  • on-xdg-desktop-* — True if the suffix (case-insensitively) is in the XDG_CURRENT_DESKTOP env var. For example on-xdg-desktop-GNOME-classic. Added 1.1.1. 🌈
  • autoprune-unless (string) — A condition that must be false for the extension to be considered unused when pruning. For example, flatpak uninstall --unused and flatpak update use this info. The only currently recognized value is active-gl-driver, which is true if the name of the active GL driver matches the extension point basename. Available since 0.11.8. 🧹
  • enable-if (string) — A condition that must be true for the extension to be enabled. As of 1.1.1, this supports multiple conditions separated by semi-colons. See download-if for available conditions. ✅
  • subdirectory-suffix (string) — A suffix that gets appended to the directory name. Very useful when the extension point naming scheme is "reversed". For example, an extension point for GTK+ themes would be /usr/share/themes/$NAME/gtk-3.0, which you could achieve using subdirectory-suffix=gtk-3.0. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.3. 📁
  • subdirectories (boolean) — If set to true, flatpak will look for extensions whose name is a prefix of the extension point name, and mount them at the corresponding name below the subdirectory. Available since 0.1. 🌳
  • no-autodownload (boolean) — Whether to automatically download extensions matching this extension point when updating or installing a 'related' application or runtime. Available since 0.6.7. 🚫
  • locale-subset (boolean) — If set, the extensions are partially downloaded by default, based on the currently configured locales. That means the extension contents should be a set of directories with the language code as name. Available since 0.9.13 (and 0.6.6 for any extensions called *.Locale). 🌍
  • autodelete (boolean) — Whether to automatically delete extensions matching this extension point when deleting a 'related' application or runtime. Available since 0.6.7. 🗑️
  • collection-id (string) — The ID of the collection that this extension point belongs to. If unspecified, it defaults to the collection ID of the app or runtime the extension point is for. Currently, extension points must be in the same collection as the app or runtime they're for. Available since 0.99.1. 🆔

[ExtensionOf] 💫

This optional group may be present if the runtime is an extension.

  • ref (string) — The ref of the runtime or application that this extension belongs to. Available since 0.9.1. 🔗
  • runtime (string) — The runtime this extension will be inside of. If it's an app extension, this is the app's runtime; otherwise, this is identical to ref, without the runtime/ prefix. Available since 1.5.0. 🏠
  • priority (integer) — The priority to give this extension when looking for the best match. Default is 0. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.3. ⭐
  • tag (string) — The tag name to use when searching for this extension's mount point in the parent flatpak. Available since 0.11.4. 🏷️

[Extra Data] 📦

This optional group may be present if the runtime or application uses extra data that gets downloaded separately. The data in this group gets merged into the repository summary, with the xa.extra-data-sources key.

If multiple extra data sources are present, their uri, size and checksum keys are grouped together by using the same suffix. If only one extra data source is present, the suffix can be omitted.

  • NoRuntime (boolean) — Whether to mount the runtime while running the /app/bin/apply_extra script. Defaults to true, i.e. not mounting the runtime. Available since 0.9.1, and backported to the 0.8.x branch in 0.8.4. 🛠️
  • uriX (string) — The uri for extra data source X. The only supported uri schemes are http and https. Available since 0.6.13. 🌐
  • sizeX (integer) — The size for extra data source X. Available since 0.6.13. 📏
  • checksumX (string) — The sha256 sum for extra data source X. Available since 0.6.13. 🔐

[Policy SUBSYSTEM] 🏛️

Subsystems can define their own policies to be placed in a group whose name has this form. Their values are treated as lists, in which items can have their meaning negated by prepending ! to the value. They are not otherwise parsed by Flatpak. Available since 0.6.13. ✨

[USB Devices] 🔌

USB devices can be enumerable or hidden by the USB portal as specified by the keys in this group. The vendor and product ids are validated by Flatpak, but aren't otherwise used or parsed. This merely grants the permission to enumerate USB device for use by the portal. This does give access to the devices. Available since 1.15.11. ⚠️

  • enumerable-devices (string list) — List of enumerable USB devices. Each element is the same syntax the arguments to --usb. Available since 1.15.11. 📋
  • hidden-devices (string list) — List of hidden USB devices, i.e. to remove the enumerable devices list. Each element is the same syntax the arguments to --nousb. Hidden devices take precedence over enumerable devices. Available since 1.15.11. 🙈

EXAMPLE 🌟

[Application]
name=org.gnome.Calculator
runtime=org.gnome.Platform/x86_64/3.20
sdk=org.gnome.Sdk/x86_64/3.20
command=gnome-calculator

[Context]
shared=network;ipc;
sockets=x11;wayland;
filesystems=xdg-run/dconf;~/.config/dconf:ro;

[Session Bus Policy]
ca.desrt.dconf=talk

[Environment]
DCONF_USER_CONFIG_DIR=.config/dconf

[USB Devices]
enumerable-devices=0fd9:*;
hidden-devices=0fd9:0063;

[Extension org.gnome.Calculator.Locale]
directory=share/runtime/locale
subdirectories=true

[Extension org.gnome.Calculator.Debug]
directory=lib/debug

Example using conditional permissions to support fallback from Wayland to X11:

[Application]
name=org.example.App
runtime=org.gnome.Platform/x86_64/3.20
sdk=org.gnome.Sdk/x86_64/3.20

[Context]
shared=network;ipc;
sockets=wayland;x11;if:x11:!has-wayland;

In this example, the application will always have access to the Wayland socket if the app runs in a Wayland session. The X11 socket only is available if the app does not run in a wayland session (!has-wayland). 🪄

SEE ALSO 👀

NOTES 📝

  1. openat2() — https://man7.org/linux/man-pages/man2/openat2.2.html
  2. steam-runtime-tools — https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/blob/65adfdd5fc812aeb5f33986755f6ff72c9612afa/steam-runtime-tools/resolve-in-sysroot.c
  3. freedesktop.org special directories — https://www.freedesktop.org/wiki/Software/xdg-user-dirs/
  4. freedesktop.org Base Directory Specification — https://specifications.freedesktop.org/basedir-spec/basedir-spec-latest.html

Source/version: flatpak; section: FLATPAK METADATA(5); date: the manpage date, bestie. That's the whole vibe. Bye! 💖🫶✨

📦 where this page comes from