User and system installations is no longer a binary decision, so remove
this API to force explicit calls to either flatpak_dir_get_system_default()
or flatpak_dir_get_system_list() when dealing with system installations.
There will be a way to retrieve the list of all system installations,
not just the default one, so we rename this for backward compatibility.
Note that some (most?) of the places where we will be now using this
renamed function will likely have to migrate to using specific system
installations, but we don't have the necessary APIs yet so we do this
as an initial step to all the incremental changes that will come next.
We recreate the OstreeRepo object in order to flush out any configuration
changes done via the system helper, so that changing the configuration works.
Should fix https://github.com/flatpak/flatpak/issues/413.
If you're building a runtime and have a base runtime with expected
extensions, fail to build if the actually installed extension is
partial (i.e. if it has a subdir specified).
Fixes https://github.com/flatpak/flatpak/issues/390
We juse use g_file_new_for_commandline_arg instead of g_file_new_for_path.
This is somewhat related to https://github.com/flatpak/flatpak/issues/401
but doesn't actually handle the specific case of tilde.
Its pretty common to e.g. ship an icon theme bundled in the app,
but you then don't want to have a warning for every file.
So, instead make this a debug message.
It makes no sense to allow you to install an application systemwide
if it only works for your user. However, its generally fine if to
install a per-user app that relies on a system-installed runtime.
In particular, this fixes installing system-wide extra-data apps where
we need the runtime to be system-installed to run the unpack script.
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.
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.
