This will be useful for testing purposes, so that we can provide
our own versions of the configuration files normally under
/etc/flatpak/installations.d.
I set these as separate bits by mistake when there's no good reason for
them to be like that, as they are not flags that are meant to be combined,
but a list of exclusive values.
This will allow explicitly referring to the default installation
using the 'default' ID, as well as overriding its values via a
configuration file specifying that same ID.
Implemented the following functions along with the required internal APIs:
* flatpak_installation_get_id ()
* flatpak_installation_get_display_name ()
* flatpak_installation_get_priority ()
* flatpak_installation_get_storage_type ()
As per the discussion with GNOME Software maintainer Richard Hughes [1],
we need to support a few additional fields in the configuration files
for better integration with external clients. Thus, this commits adds
support for reading "DisplayName", "StorageType" and "Priority" values
from the configuration files, being all of them optional.
Note: priorities are currently used to sort the system installations
list statically stored in flatpak-dir.c (bigger number, bigger priority).
[1] https://mail.gnome.org/archives/gnome-software-list/2016-December/msg00000.html
This information will be used when querying system-wide installations,
so that we can refer to those pre-configured installations by the id
defined in the configuration files under /etc/flatpak/installations.d
This will return an array of FlatpakDir instances with all the system
installations configured via key files in an optional drop-in directory
under FLATPAK_CONFIGDIR/installations.d, plus the default one.
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.
These make no sense, we don't want to modify the runtime, and
we can't create parent directories there anyway which can cause
issues like https://github.com/flatpak/flatpak/pull/433
This was manully checked in some places, which can now be dropped, but
also the places that didn't check it before were buggy and needed
to check this, so better just fail early.
When no session helper is available (e.g. running flatpak run from a
socket-activated service unit), we need to be extra careful before
making these two files appear inside the sandbox. Otherwise, if they
are not reachable on the host system (or just symlinks to non-existent
targets), flatpak won't be able to create the sandbox, which will fail
due to a "No such file or directory error".
https://github.com/flatpak/flatpak/issues/409
We already kind of support this by exposing the parent directory,
so this isn't really less secure, and you should not be able to
access it unless your user is allowed to anyway.
This lets it work during early setup phase when the new root is at
/newroot. This allows us to create things in /var/run with
e.g. --filesystem=/var/run/foo.
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
If the app is explictitly given access to a subdirectory of
one of the xdg config/cache/data directories, with read-write
(or create) access, then also bind-mount that directory
into the corresponding .var/app/$APPID directory.
This allows apps that want it to keep re-using global directories
for storing per-app information.
For instance, if your app uses "~/.config/foo" to store configuration
data, then you can use --filesystem=xdg-config/foo, which will look
for the directory, and if it exist, let the app access it, as well
as mirror the content in ~/.var/app/$appid/config/foo.
You can also use a ":create" to enforce the directory to be created
and thus always do the mapping.
