If the bundle contains an origin link we can now install related
things from it, such as locale data.
You can also build the bundle with --runtime-repo=URL, where the url
points to a flatpakrepo file for a repo with runtimes. This works
similar to the RuntimeRepo= feature in flatpakref files.
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
It's meant to provide a list of the system installations, not
just the default one, which can still be obtained by calling
flatpak_installation_new_system(), as usual.
Also, refactor code that finds and prints the references with flatpak list,
as this needed to change a bit when considering multiple installations, as
the current code was not flexible enough for dealing with that.
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.
Alexander Larsson