Flatpaks for Fedora 27

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

A proposal to add Flatpak as an option for distributing desktop applications in Fedora 27 has recently made an appearance. It is meant as an experiment of sorts to see how well Flatpak and RPM will play together—and to fix any problems found. There is a view that containers are the future, on the desktop as well as the server; Flatpaks would provide Fedora one possible path toward that future. The proposal sparked a huge thread on the Fedora devel mailing list; while the proposal itself doesn't really change much for those uninterested in Flatpaks, some are concerned with where Fedora packaging might be headed once the experiment ends.

Flatpak, which was originally known as xdg-app, is both a packaging format and a mechanism to sandbox applications that is inspired, to some extent, by container technologies (e.g. Docker). It is meant to make it easier for users to install applications by bundling any needed dependencies (beyond the standard Flatpak runtime bundle) into the package. Flatpak would make it easier to get the "latest and greatest" version of an application or to run multiple versions side by side. The sandboxing features are targeted at providing secure compartmentalization so the applications cannot interfere with each other—or escape their sandbox if they get compromised. The vision is that projects can create a single Flatpak that could be installed on multiple distributions.

The GNOME community has been instrumental in developing Flatpak and many Fedora team members have been involved as well—not surprising given the overlap between the GNOME and Fedora teams. Owen Taylor is the owner of the proposal "to enable package maintainers to build Flatpaks of their applications and make those Flatpaks available for installation". The plan is fleshed out further on a Fedora wiki page. The idea is to make it possible for package maintainers to process the standard Fedora RPMs for their packages into Flatpaks.

In order to do that, there are two pieces that need to be built: a runtime and an application. The runtime is a collection of common libraries that Flatpaks can depend on; there would be versions for each Fedora release, which could coexist on a given system. The application piece consists of the program of interest, and any additional libraries it needs, bundled up in the Flatpak-specific format (which may require rebuilding the application and libraries with different build options). The target of the Fedora proposal is Flatpaks for graphical applications, so the runtime would be filled with GNOME-specific libraries.

Proposal

In early July, Fedora program manager Jaroslav Reznik posted the feature proposal as part of the normal review process for Fedora 27 features. The first response, perhaps predictably, came from Kevin Kofler, who asked a number of important questions before concluding: "I strongly oppose this change." The proposal says that Flatpaks will be built from RPMs, but those will not be the standard Fedora RPMs for the packages, as they will need to be relocated into the filesystem hierarchy used by Flatpak. Kofler asked if only Flatpaks would be shipped for these packages or, if not, which RPMs would be available.

Taylor responded that the rebuilt RPMs are not really useful outside of the Flatpaks, though they could still be downloaded from Koji. The regular RPMs would be available along with the Flatpaks, he said. He described his vision of where this might all be leading, which is part of what caused a bit of an uproar in the Fedora world. That vision was not part of the proposal, but suggested that over the following two releases (i.e. Fedora 28 and 29), graphical applications would fully move into Flatpaks and that standard RPMs might be dropped for them. He concluded:

But this is really highly dependent on how modularity work happens more widely in Fedora. "standard RPM packaging" assumes we still have a F tag in Koji where everything is built together with common coordinated dependencies. The Change proposal, in any case is really only about enabling this as an something that packagers may opt into if they want to.

Kofler's second set of questions had to do with the advantages of shipping Flatpaks for Fedora. The existing RPM-based distribution is working and Flatpaks have only downsides, he said:

I see only drawbacks compared to RPM, because everything not included in the base runtime must be bundled, so we have all the usual issues of bundled libraries: larger downloads, more disk consumption, more RAM consumption (shared system libraries are also shared in RAM), slower and less efficient delivery of security fixes, FHS [Filesystem hierarchy standard] noncompliance, etc. And the portability argument is moot when we are talking about delivering Fedora software to Fedora users.

Taylor said that he believed the proposal itself answered that question in its "Benefit to Fedora" section, which lists several benefits. The main ones seem to be that it allows application maintainers to choose their dependencies separately from the versions in the Fedora release, it provides a way of testing different versions of applications, and that it can sandbox some applications. Bastien Nocera disagreed with Kofler's assessment; he dismissed the FHS compliance question and questioned the assertion of slower security fixes, while also listing his set of "positive changes".

Sandboxes

Kofler pointed out the problems he sees with rebuilding the libraries for the Flatpak layout; he also described ways that the process of updating Flatpaks will lead to slower security fixes. But a good chunk of his response concerned sandboxing; he is not convinced that the "Flatpak way" is the right way forward. Michael Catanzaro acknowledged many of Kofler's points, but was enthusiastic about the Flatpak sandboxing. But, as Andy Lutomirski noted, there are two elements to Flatpak that aren't necessarily tied:

Flatpak provides two things that are very nearly orthogonal: packaging and sandboxing. Packaging is the system of bundles, apps, runtimes, etc that allows you to build a Flatpak, send it to a different machine, and run it there, even if the other machine runs a different distro. Sandboxing is Flatpak's system of portals, confinement, etc. Aside from the fact that both are based on namespaces, I see no reason at all that they need to be conflated. It should be entirely possible for Flatpak [to] run an "app" that is actually a conventional RPM installed on the host system using host libraries.

So, if sandboxing can be provided by other means, "what on earth is the point of forcing packagers to make Flatpaks?", Richard W. M. Jones asked. Others agreed with that assessment and wondered what Flatpaks provide that can't be solved with RPM packages. But it is a rare Fedora system that only has RPMs from Fedora repositories installed, as Bill Nottingham pointed out. Typically systems are built up from other sources as well: Coprs, RPMs from elsewhere, packages from language-specific repositories (e.g. PyPI), containers from various sources, packages retrieved using curl , and software built from tarballs. He continued:

If the only answer Fedora has for this is "convince everyone to only build RPMs using system [repo] components"... that's fighting a rear-guard battle that has already been lost. I don't think supporting Flatpak apps is necessarily any worse than what already has to happen with all of the above.

And Flatpaks do have some other advantages, as Taylor outlined:

There are no scriplets with [Flatpaks] - no arbitrary code execution at install time.

There is no ability for Flatpaks to drop arbitrary files at arbitrary locations on your system. Well, the nice thing is that: The idea is that you don't *have* to inspect a flatpak before installation to make sure that it's not dangerous.

Fedora == RPM?

But in another sub-thread, Kofler wonders why users would get Flatpaks from Fedora; why wouldn't they just get them from upstream? RPMs are an important feature of Fedora, he said:

The whole point of delivering software under the Fedora umbrella is to deliver it as RPMs. If there is no RPM, delivering through Fedora is completely useless.

Fedora project leader Matthew Miller took exception to that characterization: "I strongly dispute the idea that Fedora must be tied to a particular packaging technology." But Stephen J. Smoogen agreed with Kofler, at least from a branding standpoint: "RPM is part and parcel of what makes Fedora for most people." Others, including Miller, disagreed; various examples, counter-examples, and car analogies were offered up, but it seems there are some fundamentally different views of what Fedora is.

The "plan" that Taylor outlined is part of what has gotten some in the Fedora community riled. It posits a future without RPMs, at least for some packages, but it is only Taylor's vision, not something that is currently being considered. As he put it:

But I want to be clear that there is no *proposal* on the table to ship things Flatpak only, and *no proposed timescale*. And there won't be until we know how the tools work out for packagers, how Flatpak usage works out for users, and we have a significant body of Fedora packages built as Flatpaks to look at things like installed size and network usage. These are things we can only get to by building out the infrastructure so that packagers can start trying building Flatpaks and users can start trying installing them.

The intent seems to be to test out Flatpaks in a "real world" environment to see what advantages, problems, and downsides they have. Many, including Miller, believe it is in keeping with the nature of the distribution to do that kind of experiment. There are a number of ideas swirling around the industry these days, and containerization is one of them, so it makes sense for Fedora to explore that, Christian Schaller said:

Containers have caught on due to solving some important problems and thus people are looking at models for what the future operating system would look like where containers are the primary content delivery mechanism. In Fedora we have efforts [around] Docker/OCI containers and Flatpak containers and we are looking at image based OS installs with the Atomic and Atomic Workstation effort. The fact that we are developing stuff like this in Fedora is a good thing as it means that if it does turn out to be a better model we are well positioned to take advantage of the shift in the market. And if the scepticism some people have about containers turns out to be well founded we still have our RPM based OS to fall back on.

The Fedora Engineering Steering Committee (FESCo) took up the proposal at its July 21 meeting. As can be seen in the log (starting at 16:04), FESCo members noted the opposition, but found that it was mostly ideological differences over packaging formats. Adding Flatpaks in parallel to RPMs is not really harming anyone or anything. If the experiment is successful, perhaps there will be other proposals down the road that do change the picture with regard to RPM availability, but those can be dealt with then. In the end, FESCo unanimously approved the proposal, so Fedora 27 should be a good testbed for those who are interested in trying out Flatpaks.