Handling multiple flatpak system installations

[Mario Sanchez Prada <msanchez gnome org>]

Hi,

Today Richard and me met to discuss the implications of the new feature
being implemented for flatpak to allow multiple system installations [1],
and here is a summary of the notes I took:

The current version (pending on review [2]) allows defining additional
system installations living in alternative paths. From the pov of flatpak's
CLI, you'd be passing a --installation=<id> parameter when needed.

On disk, this additional installations will look like /var/lib/flatpak
(which will be still considered as the 'default' system installation) but in
a different place, meaning that they will have their own full OSTree
repository with its remotes config, deployed flatpaks and exports directory.

The _main problems_ identified so far with this approach where:

 1. Being separate installations means we need to define remotes there even
    if they are already defined in /var/lib/flatpak/repo/config, leading to
    some duplication.

 2. Separate OSTree repositories means that we'd have to full from two
    OSTree repos, even if we are referencing the same remotes.

 3. The exports/ directory won't be discoverable by the desktop unless we
    somehow add the alternative paths into XDG_DATA_DIRS

**About (1)**, we thought for a while about it and we think that, while it
would inevitably add some work on GNOME Software, it should not be a problem
from an user's perspective if handled correctly:

- From a vendor's point of view, OS images would ship with the desired
configuration, which might not mean necessarily 100% duplication in remotes
config (e.g. Endless will only add the 'eos-apps' remote in an external).

- When configuring remotes from GS (e.g. via .flatpakrepo), it would have to
be configured in all the system installations, so that later on we can
decide which one to use based on some logic inside GS.

- The "accidental benefit" of having a single unique ID for system flatpaks
regardless the system installations they're coming from can be used to keep
the app de-duplicated inside GNOME Software, which would allow to defer the
decision of where to install the application to until the very last moment.

- GS would avoid showing the same app twice if coming from the same remote,
regardless of the associated installation, and should never allow
installing/updating an app in more than one installation (you could still do
it from command line of course, but GS would not support that scenario).

- Finally, the decision of installing an app in one system installation or
another would happen at the time of hitting the "Install" button, when the
gs-plugin-flatpak plugin could decide which GsFlatpak to use deciding based
on a "hint" that would be set and passed via metadata from downstream
plugins (e.g. gs-plugin-eos) if present, or simply based on some simple rule
implemented as fallback (e.g. "pick the first one").

**About (2)**, we thought that a deployment interested in this kind of setup
could always define the OSTree from the default system installation (or any
other) as the parent repo for the one in the external installation, which
should help alleviate the amount of data that needs to be pulled from the
network for "duplicated" remotes (e.g. appstream branch)

**About (3)**, it seems that this is not a new issue (see
https://github.com/flatpak/flatpak/issues/25) and probably the right way of
addressing this would require fixing
https://bugzilla.gnome.org/show_bug.cgi?id=767933 first. In the meantime, as
a middle ground solution that would only work for X11, we could make the
/etc/profile.d/flatpak.sh script craft the contents of the XDG_DATA_DIRS
variable based on the output of some 'flatpak installation-list' command,
yet to be written (we can't do this for Wayland since in that case the
/etc/profile.d script won't be read when starting the session, and the
keyfile in /usr/share/gdm/env.d won't allow this trick.

Finally, we identify additional API that would be needed in flatpak so that
GS can do the right thing in terms of UI, some of them already in the PR:
 - flatpak_installation_new_with_id() -> FlatpakInstallation*
 - flatpak_installation_get_id() -> string
 - flatpak_installation_get_name() -> string
 - flatpak_installation_get_type -> enum type { HARD_DISK, MMC, SDCARD }
 - flatpak_installation_get_priority -> signed integer
 - flatpak_installation_get_system_list -> GPtrArray* [FlatpakInstallation*]

I plan to take care of the flatpak related bits for now and push that to the
PR in [2] on Monday. Then, once this is reviewed and merged, we could work
on the GNOME Software bits as needed.

Hope this make sense. Any comments?

Thanks,
Mario

[1] https://github.com/flatpak/flatpak/issues/137
[2] https://github.com/flatpak/flatpak/pull/418