Fedora needs to embrace Flathub, and here’s how that could be done

Earlier this year, we talked about a peculiar oddity concerning Flatpaks and Fedora: unlike just about any other distribution, Fedora maintains its own Flatpak repository, while everyone else just defaults to Flathub. While there’s a few technical differences between Fedora Flatpaks and Flathub Flatpaks, the main gist is that the Fedora ones are built using Fedora’s own RPMs, while Flathub’s are built using different means.

This is an odd situation, since it does not reflect what users really want – users seem to greatly prefer Flatpaks from Flathub, since they have fewer bugs, are packaged by the applications’ creators, and bugs in Flathub Flatpaks can be reported to the actual developers, whereas bugs in Fedora Flatpaks generally cannot. As such, Fedora users are often surprised to learn that the Flatpak they installed came from Fedora instead of Flathub.

Now, since Fedora’s long-term goal is to make their immutable, Flatpak-focused variants the default, this situation needs to be addressed. As such, Fedora and GNOME developer Michael Catanzaro has published an incredibly detailed article outlining all the issues and possible solutions and courses of action. The basic gist is that before Fedora can consider switching from its own Flatpak repository to Flathub, a number of shortcomings in Flathub must be addressed:

Open source software must be built from source on trusted infrastructure.

Applications must not depend on end-of-life runtimes.

Applications must use flatpak-external-data-checker to monitor bundled dependencies wherever possible.

Sandbox holes must be phased out, except where this is fundamentally technically infeasible.

↫ Michael Catanzaro

Some of these points are fairly obvious, but let’s go over them anyway. A lot of binaries on Flathub are pre-built in that they are not built using Flathub’s infrastructure, and as such, you don’t know if anything has been done to the code between, say, the code’s release on GitHub and the Flatpak you install on your computer. This obviously needs to change, and ideally, all Flatpaks on Flathub should be reproducible.

End-of-life runtimes should obviously also not be a thing, for entirely obvious reasons. Currently, a little under a third of applications on Flathub use end-of-life runtimes, meaning the runtimes they use are not receiving any security updates. The same applies to external dependencies packaged inside Flatpaks; they can be outdated too, but many Flatpaks do not use the designated tool to deal with this issue. Obviously, holes in the Flatpak sandbox should not exist either, again for entirely obvious reasons.

Catanzaro proposes a number of solutions to all of these problems, which require work from both Fedora and Flathub to be implemented. On top of that, even once these issues are satisfactorily addressed, there’s a debate to be had over the exact way in which both the traditional and immutable variants of Fedora move on over to Flathub – the variant I personally like the most is where the core applications installed by default remain in control of Fedora, while everything else gets installed from Flathub.

Of course, this is not of much relevance to people who prefer plain, traditional RPMs – such as myself – to whom Flatpaks are more of a “if all else fails” option than a default. While the immutable, Flatpak-based variants of Fedora are definitely on their way to become the default option, the traditional RPM variants will not be going anywhere, and will remain an option as well. I think defaulting new users to the immutable variants is the way to go, even if I personally won’t be using them.