Distributors entering Flatpakland
A traditional binary package from a distribution contains the program of interest, of course, along with any supplementary files that it needs. The package also carries metadata describing, among other things, which other packages must be installed for the program to work. The distribution's package manager uses that dependency information to ensure that every package is properly installed.
The Flatpak format has been described as "just another distribution format" and, to an extent, it is true. A Flatpak package (or, simply, "a flatpak") has everything that a .deb or RPM package would have, but there are some significant differences. Perhaps at the top of the list is the way that dependencies are handled. A traditional package will have a (possibly long) list indicating every other package that is needed; a Flatpak package, instead, will list a single "runtime" containing the base set of libraries against which the package is built. If there are libraries or other dependencies that do not appear in the runtime of choice, they are simply bundled with the application in its flatpak.
This arrangement has a certain appeal to packagers. The "runtime plus bundling" approach simplifies dependency management, and the ability to bundle patched versions of system or runtime libraries is called out as a Flatpak feature. A package built against a given runtime can be installed on any system that has that runtime installed, making it possible to build a single package that can be installed on multiple distributions. Distributors can thus use this format to make their lives easier; purveyors of proprietary packages also see some obvious charm in this idea.
In a sense, Flatpak has set out to solve many of the same problems that the ill-fated Linux Standard Base effort addressed many years ago.
Flatpak is designed to work with distributions that are built around an immutable core; it will not install into system directories like /etc or /usr/bin. That makes it attractive for distributors that are trying to create that sort of offering.
One other key selling point for Flatpak is the built-in sandboxing mechanism. Applications installed with Flatpak will, by default, be run inside a container that has almost no access to the underlying system or the Internet. Through declarations in the manifest file used to build the package, a specific application can request access to, for example, the user's local files, the Internet, or the window-system server. In theory, at least, this sandbox makes installing packages safer and limits the damage that can be caused by a compromised or malicious package.
Flatpak is not without its critics. While packages can share the same runtime, there is nothing to prevent a proliferation of runtimes and versions; that already seems to be happening to an extent. Both the runtimes and the packages themselves are large, significantly expanding the amount of storage space and memory consumed. It is common for applications to request access to local files and the Internet whether they need it or not, to the point that some see Flatpak's sandbox claims as being more hype than reality.
All of that adds up to a certain amount of opposition to the use of Flatpak. It also seems possible that much of the opposition to Flatpak may result from an instinctive resistance to changing the way things have always been done.
Fedora's (un)filtered Flathub
On the Fedora side, the discussion has been stirred up by this Fedora 37 change proposal removing the filters currently applied to the Flathub package repository in Fedora's GNOME Software application. Once the filter is gone, all of the packages available on Flathub, including those containing proprietary software or programs that, for reasons such as patent concerns, cannot be shipped with Fedora, will be available to be installed. Flathub as a whole will still be disabled, though, unless users enable third-party repositories.
The advantages of this change are said to be that it makes more software readily available to Fedora users and makes that software more secure by sandboxing it. The latter reason is part of why the GNOME Software tool will prefer flatpaks over traditional RPM packages when both are available. But there are some vocal members of the Fedora community who are strongly opposed to the idea. Vitaly Zaitsev, for example, complained about the preference for flatpaks, saying that it would cause flatpaks to replace RPM packages as a system is updated. A lot of the points mentioned above — install size and porous sandboxes, for example — have come up in this discussion, as has the perceived bias against the RPM Fusion repository, which was discussed in depth here in June.
It seems unlikely that these objections will stop the unfiltering of
Flathub — or the transition toward Flatpak in general. The distribution
seems committed to that direction, and the Silverblue variant, which
is built around an immutable core installation, already
requires Flatpak. In the discussion, Michael Catanzaro extolled the
security benefits of the format and pointed out that, despite years of
complaints, Flatpak opponents have not come up with a viable alternative
that provides similar security benefits. Richard Hughes argued
that "flatpaks are in almost all cases what users should be using
".
Unless something changes, it looks like full speed ahead for Fedora's
Flatpak future.
OpenSUSE's ALPs are flat
Back in April, SUSE announced an effort known as the "Adaptable Linux Platform" (ALP) that is, in some way, meant to define the future of the SUSE Linux Enterprise (SLE) distribution. There was a lot of text about how the process would be open, but outside observers might be forgiven for thinking that ALP remains fairly murky so far. There is not much public information yet on just what ALP will be or how it will affect either SUSE's enterprise offerings or openSUSE. The hints that have come out, though, suggest a distribution built on a small, immutable core with applications managed separately, most likely using a format like Flatpak.
On July 5, Dan Čermák posted the
minutes from a meeting of the ALP working group that was focused on
"how the ALP Desktop is going to look like and how we can dispel fears
around flatpaks and containers when it comes to the ALP desktop
". The
minutes note that Flatpak will indeed be used as a distribution format, but
stressed that there would be no need to install flatpaks from external
sources like Flathub; "the packaging model will not change, only the
format
".
When asked about the benefits driving a switch to flatpak, Čermák mentioned the sandboxing mechanism, but said that the main advantage was in the reduction of packaging work. Desktop applications like Firefox or LibreOffice could be built once on the rolling openSUSE Tumbleweed distribution, then shipped for Tumbleweed, Leap, ALP, and presumably anything else SUSE might create. It is not hard to see why distributors are attracted to an option that could significantly decrease the amount of work required to maintain current packages of complex applications.
There was some fundamental opposition to use of Flatpak in the openSUSE
community as well. Robert Kaiser, for example, said
"if there's no RPM-based distro left without that weird packaging like
flatpak, it's probably time to go back to Windows
". As a whole,
though, the openSUSE community seems less stirred up by the prospect — so
far at least. There may be a few reasons for that, including a relative
lack of experience with Flatpak in the openSUSE community and the amorphous
nature of ALP in general. But this
reassurance from Čermák can only help as well:
Tumbleweed will be the place where development is going to take place, but there are no plans to fundamentally alter Tumbleweed. You'll still be able to use Tumbleweed like you used before. Additionally, you'll be able to use the "containerized stuff", but you won't have to, at least for the foreseeable future.
There may soon come a time where use of Flatpak on Fedora is unavoidable, at least when it comes to installing certain complex applications. Thus far, openSUSE does not appear to be driving in that direction, so Tumbleweed users (who make up a large part of the openSUSE community) need not fear being pushed unwillingly into the Flatpak world.
One should not underestimate the value of that last point. Much of the bitterness around the systemd transition was certainly caused by the feeling that it was being forced on users who were happy with their existing setup and felt no need to change. Even if Flatpak is as great as some claim, a poorly handled transition risks creating similar levels of unhappiness.
That transition seems likely to come; in a later
posting Čermák questioned the value of packinging some complex
applications and suggested that they may be made available only in flatpak
form if they are shipped by the distribution at all. Robert Schweikert said
more succinctly: "What we have today has worked reasonably well for
probably about 30 years but the model is certainly showing it's age
".
Evolving to meet current needs is exactly what the distributors need to be
doing, and that evolution will surely bring changes that are visible to end
users. The key will be handling the changes with sympathy for those users
and, hopefully, avoiding some of the turbulence we have seen with past
changes.