FlatPak package and repository

[Mailaender]

I propose using http://flatpak.org/ to create a centralized package (and update repository) for Linux. This has the benefit of focusing our limited packaging resources on package specification instead of multiple incompatible ones for Ubuntu/Debian and openSUSE/Fedora/CentOS as well as the new ones that are constantly invented.

Flatpak seems to have commercial backing from RedHat and is a vendor neutral Freedesktop project. It is used by the @mono project which can serve as a template http://apebox.org/wordpress/linux/1184 With Flatpak 0.8 there is now a stable foundation https://blogs.gnome.org/alexl/2016/12/22/a-stable-base-for-flatpak-0-8/ we can build upon.

It has been successfully integrated https://news.opensuse.org/2017/01/26/new-package-in-tumbleweed-enhances-rolling-updates/ in @openSUSE and the @solus-project is also planning to support it soon. https://solus-project.com/2017/01/18/adopting-flatpak-to-reassemble-third-party-applications/

[pchote]

I support investigating this as an alternative installation channel, but we'll probably need to give it a bit more time to bake before we can consider dropping our other packages. Requiring users to run things from the terminal is quite a step back from OpenSUSE's one click interface or even downloading an double clicking a deb package.

[Mailaender]

I had a deeper look https://github.com/mono/monodevelop-flatpak At the moment it means building Mono (as there is no runtime for it) and setting up a webhost. https://blogs.gnome.org/alexl/2017/02/10/maintaining-a-flatpak-repository/ There is also https://flathub.org/ if we don't want to do it ourselves and gain better discoverability. It requires an offline build (no dependency fetching from the internet) just like http://build.opensuse.org The good thing is we get #2585 and #3041 for free as there are different release channels and auto-update support via GNOME Software and the KDE equivalent.

[Unrud]

https://github.com/flathub/net.openra.OpenRA

[Mailaender]

Thanks! https://github.com/OpenRA/OpenRAWeb/blob/master/content/download.html needs instructions on how to install it.

[Mailaender]

Just discovered it perfectly integrated in GNOME Software in @openSUSE Tumbleweed:

with auto-generated instructions at https://flathub.org/apps.html#OpenRA so I consider this done. Wrote a small paragraph at https://en.opensuse.org/OpenRA#Flathub for improved visibility.

[penev92]

👍

[pchote]

IMO we shouldn't consider this complete until it is integrated into our automated deployment to avoid the same (lack of) maintenance issues that our other external sources suffer from.

[Mailaender]

I doubt @flathub will allow that. It is an independent project that has nothing to do with OpenRA just like the openSUSE build service instance.

[Mailaender]

OpenRA/OpenRAWeb#365

[pchote]

Flatpak packages can be compiled into single file bundles which can be opened directly with the Gnome software center (and I assume similar tools on other DEs).

Reopening this ticket because having our own automatically updated package is important, and I don't see any real technical barrier to offering one (aside from working out how to package it on travis). It is not good enough to tell players that they can't play online with their friends during the ~week after a release because the fedora or arch (or etc...) packages have not been updated yet and we can't help and don't know when that will be fixed.

These .flatpak bundles are able to configure a repository for automatic updates (see https://firefox-flatpak.mojefedora.cz/ for an example), however these repositories cannot be hosted on github. I expect that the first implementation would push a static bundle (without automatic updates) to the github release, just like the deb package (and possibly superseding it), and that future work could implement pushing to a flatpak repo on the master server.

At some point I'd like to prototype this with/for the Mod SDK (instead of OpenRA/OpenRAModSDK#56).

[pchote]

I doubt @flathub will allow that.

I should have investigated this first instead of taking it as read, because it looks simple to automate deployment.

Any updates to the local flathub source repo will automatically trigger a build and update on the main package repository. Adopting ownership of https://github.com/flathub/net.openra.OpenRA (as preferred by flathub) would let us give @orabot push access to update the package metadata using the same authentication boilerplate as the wiki updating during deployment.

[pchote]

After spending some time with it I am quite impressed with how simple and relatively clean the Flatpak system is for both users and developers. With one exception: the sandbox breaks our cross-mod switching, and there doesn't seem to be any replacements, workarounds, or even (as far as I can tell) a lot of interest upstream to solve the problem of cross-application communication.

We can fix the metadata registration and consuming by properly sharing the ~/.openra directory ("--filesystem=~/.openra") and enabling read-only access to the rest of the filesystem ("--filesystem=host:ro"), but there is no way to break out of or switch to a different sandbox to launch another isolated OpenRA instance.

This is one of OpenRA's tent-pole features, so I can't get behind promoting Flatpak for OpenRA until there is a solution.

[pchote]

There are two potential solutions for launching other mods:

• Flatpak exposes a HostCommand API to escape the sandbox
  • flatpak/flatpak@c8df0e6
  • https://stackoverflow.com/questions/39494813/pass-file-descriptor-via-a-dbus-function-call-from-python-aka-call-flatpaks-ho
  • https://stackoverflow.com/questions/39494813/pass-file-descriptor-via-a-dbus-function-call-from-python-aka-call-flatpaks-ho
• It may be possible to launch directly using DBus:
  • https://media.readthedocs.org/pdf/flatpak/latest/flatpak.pdf (page 13)
  • https://wiki.gnome.org/HowDoI/DBusApplicationLaunching

[Mailaender]

https://openbuildservice.org/2021/02/18/introducing-flatpak-builds/

[Mailaender]

IMO we shouldn't consider this complete until it is integrated into our automated deployment to avoid the same (lack of) maintenance issues that our other external sources suffer from.

https://github.com/flathub/net.openra.OpenRA uses https://github.com/flathub/flatpak-external-data-checker/ to automatize this.