Fedora’s Flatpak Flak

Fedora’s Flatpaks are a topic of frequent discussion, with a number of developers suggesting that they should be dropped from the project. But some of the high profile problems that have been discussed don’t seem to have been caused by Flatpak, and ironicly, I think they illustrate a problem that Flatpak can solve in some cases.

For example, early in 2025, a non-functional Fedora Flatpak was published which exhibited bugs that were not present in the same application on Flathub1. The affected version contained the most recent versions of the application and its dependencies. This Flatpak differed significantly from the Flatpak that the developer published to Flathub, and from other builds of the application published by the developer, because one of Fedora’s policies generally prohibits bundling applications with their dependencies. Whereas the developer’s own releases generally include a version of key dependencies that they have tested, a Fedora system and Fedora Flatpaks update dependencies for all applications, globally.

The problem in this case was that a system library initially contained a regression (a bug that did not affect earlier releases). Because Fedora updated the library before the application’s developers had tested and validated that release, Fedora’s packages and Flatpaks did not function normally.

A traditional stable release platform (such as the base layers provided by Flathub) provides a fairly straightforward solution to problems like this one. Application developers can test their application and validate platform releases individually. And in the context of containerized platforms like Flathub, users and developers both get the benefit of decoupling the application and its supporting platfrom from the OS that runs on bare metal. So in the case that an application developer has not yet tested their application on the newest platform release, or if they have found bugs in the new platform release, users can still use the application even if they’ve updated the OS they run. That’s the practical benefit of the stable release model.

There were two significant reasons that Fedora was impacted while Flathub was not.

The first issue is that while Fedora’s release policy[^2] suggests that “updates should aim to fix bugs, and not introduce features,” this project is not strict about shipping minor-version updates, even when the upstream project continues to support the release series that a Fedora release shipped with. That means that even in the best case, Fedora releases often update a component in all actively maintained releases, so there’s no fallback release. Fedora’s policy suggests a stable release, but in practice a lot of components roll through minor releases.

The second issue is that the system library implicated in this case was QT, and QT itself is a rolling release[^3]. Or, at least, the Free Software release is. The QT developers do maintain stable releases of QT, but only the releases in the most recent release series are available to the public under the GPL. The overlapping portions of older release series are only available to commercial licensees. QT is a security-critical component, so in order to protect user security, QT more or less must be treated as a rolling release in Fedora.

For most software, Flatpak actually can be the solution to this class of problems. When Fedora releases stick to a stable release series within a distribution release, users can expect to see different releases of a given component in one Fedora release vs another. And that means that when an application is affected by a regression in a dependency, a Fedora flatpak can use a Fedora release that is not affected by that regression as its base. Flatpak can actually solve, in many cases, the exact problems that it is accused of causing.

But that requires that Fedora sticks with minor-version stability, which it often doesn’t. And it won’t help when components are security-critical and rolling releases upstream.

Rolling releases require different solutions.

Other solutions

One of the processes that I advocate most often is one that used to be much more common: nightly builds. Specifically, I advocate the process of building an application and it key dependencies directly from their respective VCS release branches and publishing the entire bundle.

Nightly builds that include key dependencies are a Free Software superpower, not possible in the proprietary software world.

In the proprietary software world, builds typically rely on releases of shared components, and the development model is very reactive. Application developers wait for the release of the libraries and platforms they build on, and port their applications to the finished interfaces. In the free software world, we can build something better.

Free Software is fundamentally different from proprietary, commercial software, and we should not confine ourselves to the kind of reactive workflows and development processes that exist in the proprietary software world. We have access to the source for shared components, and don’t need to wait for releases. We can be proactive instead of reactive. We can treat the application and its dependencies as one coherent code base.

When combined with builds of key dependencies, nightly builds can serve to identify regressions and bugs earlier, especially when bugs result from complex interactions between an application and its dependencies.

Nightly builds are not just a way to push testing onto users who can report when something breaks, they’re an opportunity for developers to provide feedback on new features and design changes in platforms that support their application, before the changes reach a final release state, when it is too late to fix them. And in the same fashion, they offer advanced users of applications the chance to give developers feedback on the design of new features before they’re finalized. Enthusiasts and professional users both benefit from early access to new features as they are being developed, and developers benefit from the feedback they provide describing their workflows, and how features do or do not integrate into those workflows.

Nightly builds enable collaboration, which is central to the Free Software ethos.

There are no silos in Free Software

Collaboration is the most important function of nightly branch builds.

Nightly builds composed of an application and key dependencies encourages developers to see their application and its dependencies not as siloed and separate components, but as one cohesive code base.

In the commercial software world, it is normal for application developers to pay the developers who provide them with platforms, development tools, and shared libraries. Paying for that support creates the reasonable expectation that development and maintenance of those shared components is someone else’s responsibility. It shields application developers from the responsibility of maintaining a code base beyond their own.

None of that exists in Free Software. There are no silos. When an application developer needs a feature from the platform, no one else bears the responsibility of developing that feature. If an application developer uncovers a bug that affects their application, there is no “vendor” who is responsible for fixing it. The responsibility to develop and maintain the platform rests equally upon everyone.

In the Free Software model, application developers typically don’t support their dependencies financially, the way that commercial software developers do. Instead, it’s critical that we support our dependencies through participation to ensure that they are sustainable.

Conclusions

  • The stable release process gives Fedora a way to address regressions, but only if maintainers implement the stated policy[^2] that “updates should aim to fix bugs, and not introduce features”
  • Flatpak isn’t the problem, it’s the solution. Decoupling applications from the components running on bare metal allows Fedora maintainers to publish applications with the dependency set that works best, and to publish that application to users regardless of what release they are running.
  • Whenever possible, Fedora maintainers should work with application developers to determine optimal deployment details, like what base layer to use.
  • Fedora is a system that builds and integrates applications and platforms. It is effectively a big CI system for releases. One of the things that I hope we can do to create value for application developers is to use our experience building CI systems to help application developers create CI pipelines that remove friction in their workflows, and connect them to the rest of the ecosystem.

Footnotes

  1. The application is unnamed because I don’t think the application’s developers are at fault. [^2]: Fedora’s updates policy [^3]: Please see definitions and context regarding the terminology used here. ↩