This means we will not end up with a partial download if something
goes wrong during the extra-data download, because we don't
commit the downloaded base files until everything is finished.
Note, this requires the latest ostree for this feature.
The g_key_file_load_from_bytes() function was added in GLib 2.50, and that
is too high as flatpak wants to support centos7/rhel7, which is now in 2.42.
We want to use the new transactioned detached metadata support,
multi-subdirs pull, and inherit-transactions on pull. Also, there are
some fixes we like.
If the downloaded app has a "xa.extra-data-sources" property in
the commit, then we download these as part of the pull operation
and store the result in the commitmeta object in the repo.
Then during deploy we look at the xa.extra-data-sources properties
again and extract them from the commitmeta into /app/extra
in the app, and afterwards we run /app/bin/apply_extra in a minimal
sandbox that has read-write access to /app/extra, but nowhere else.
There are some complexities:
We need to re-verify when extracting, because the commitmeta is not
really signed, so we could have picked up random stuff there
from the upstream repo, or from an attacker misusing the system-helper
local install codepath.
When using the system-helper the pull will fail if the commitmeta
is to large, so we have some code in this case to manually transfer
the larger commitmeta on the side to the local-pull code.
If you put a section like:
[Extra Data]
uri=https://sdk.gnome.org/gno%6De.flatpakrepo
checksum=ace1b504d32eefdf05b53044e6f785fe7886cc5657b5df034c3b9ac8e3aeb70c
size=1335
uri2=http://sdk.gnome.org/gedit.flatpakref
checksum2=d8baa109fb5fdcfe90379f3e93c5ab29f11772b42bf569bb3481e4aff489b0dd
size2=1472
name2=renamed.flatpakref
Then this information will be put in the commit object and the
later will be used when downloading the app.
This allows you do do something like
flatpak build-finish --add-policy=subsystem.key=v1 --add-policy=subsystem.key=v2
Which maps to this metadata keys:
[Policy subsystem]
key=v1;v2;
You can also --remove-policy to remove values from a key.
The policy values are parsed from the app and runtime metadata, and
are overridable by per-app overrides and on the command line, however
the values are never used by flatpak. They do end up in the flatpak-info
file for the running application though, so external agents can look
at them.
These
This means you can do:
flatpak run org.freedesktop.Sdk
to get a shell in a sandbox with that runtime, but with an
empty /app.
You can also specify a particular runtime branch and command like so:
flatpak run --command=ls org.gnome.Platform//3.22 /
Use FLATPAK_TESTS_VALGRIND_LEAKS to check for leaks.
We're not currently passing the leak checks, so this helps letting
us make valgrind checks useful.
When an application requires a runtime that is not installed, search
for it and prompt for permissions to install it. Also, update required
runtimes when the app is being updated.
If this is set for a remote we will never automatically look for
dependencies in it. This makes dependency search faster, as we
don't need to search in app-only remotes.
Otherwise we'll be always trying to force the installation from the
default branch for a repo, regardless of whether the app being
installed is available for that branch.
It can happen, like in https://github.com/flatpak/flatpak/issues/353
that there are references in the source to the absolute source path.
We need to ensure that is visible in the build. We mostly do this,
but for technical reasons it didn't get the same pathname when
the source was inside a symlinked directory. We fix this with an
extra bind-mount to the symlinked directory name too.
This fixes https://github.com/flatpak/flatpak/issues/353
Make sure we can only send message calls (not e.g. unicast signals)
to the bus. Also, whitelist the list of allowed interfaces to
org.freedesktop.DBus and org.freedesktop.DBus.Introspectable
See https://github.com/flatpak/flatpak/issues/343 for the origin
discussion of this.
When initializing a build you can initialize the application directory
with the files from another directory, and optionally a set of its
extensions. This allows one to create a "base" application that
can be derived from in multiple forms. A typical example is an application
framework like Electron. The base electron app has all the dependencies
needed to write Electron app, and then your manifest can add the specific
files needed for your application.
An example snipped could look something like:
"base": "org.base.App",
"base-version": "stable",
"base-extensions": ["org.base.app.Locale", "org.base.app.Debug" ],
