Flatpaks for Fedora 27

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:

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:

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:

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:

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

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:

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:

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:

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.

Note: you can avoid this step in the future by logging into your LWN account.