Catanzaro: Fedora must (carefully) embrace Flathub

[Posted July 22, 2025 by jzb]

GNOME and Fedora contributor Michael Catanzaro has written a lengthy blog post about the future of Fedora Workstation as an image-based release and the need to enable Flathub by default. He writes that the Fedora Workstation of the future must be "safe and image-based by default", with applications provided through Flathub:

Flathub is drastically more popular than Fedora Flatpaks even among the most hardcore Fedora community members who participate in change proposal debate on Fedora Discussion. (At time of writing, nearly 80% of discussion participants favor filtering out Fedora Flatpaks.)

This is the most important point. Flathub has already won.

He notes that Fedora should not force users to install an image-based OS if they do not want to, and there will be a package-based version for users who prefer or require it: "so no need to panic".

Fedora Flatpaks creates more work

Posted Jul 23, 2025 5:03 UTC (Wed) by numgmt (guest, #167446) [Link] (1 responses)

I had to step through a user who was having bizarre issues with a package that I could not reproduce on the same Silverblue system. After several comments and hours of debugging, I realized the user had mistakenly installed the Fedora Flatpak version of the package instead of the Flathub package. The Flathub package worked fine.

They were as frustrated as I was when they realized this, and immediately removed the Fedora Flatpaks repository and reinstalled everything via Flathub.

If anything, I'm a proponent of hosting your own Flatpak repository. I help maintain a Flatpak bundle that isn't hosted on any repositories, and I'm glad Flatpak is flexible enough to allow for that. But Fedora Flatpaks is a bad, confusing user experience that unintentionally creates more work for upstream developers/packagers in some cases.

Fedora Flatpaks creates more work

Posted Jul 23, 2025 5:09 UTC (Wed) by numgmt (guest, #167446) [Link]

The relevant issue... https://github.com/flathub/io.github.celluloid_player.Cel...

If Flatpaks are reproducible why not build them?

Posted Jul 23, 2025 7:17 UTC (Wed) by epa (subscriber, #39769) [Link] (3 responses)

He mentions that Flathub’s images are more popular than the ones Fedora provides. And others have noted problems when installing the Fedora package instead of the Flathub one, which worked better.

But this is all free software we are talking about. If Flathub has a useful package, surely you can pull down the source code (and manifest file giving dependencies, etc) and build it. Fully bit-for-bit reproducible builds might not be there yet, but the work done on that ought to apply to Flatpaks too.

In any case it seems sensible to have a second source for the images, and a check that they really can be built from their claimed source code and build scripts.

That doesn’t mean duplicating the work that Flathub and the upstream packagers do, although Fedora would have the option to make local patches and build a slightly different image (just as RPM source packages can include patches), or occasionally to maintain its own version of an application if there are reasons the Flatpak one isn’t appropriate.

If Flatpaks are reproducible why not build them?

Posted Jul 23, 2025 7:45 UTC (Wed) by taladar (subscriber, #68407) [Link] (2 responses)

I think this isn't about the images, this is about two entirely different packaging efforts for the same upstream project using the same packaging technology, one done by upstream and published on Flathub and one done (apparently badly) by Fedora and published only to their users.

If Flatpaks are reproducible why not build them?

Posted Jul 23, 2025 17:42 UTC (Wed) by pizza (subscriber, #46) [Link] (1 responses)

> and one done (apparently badly) by Fedora

It's worth mentioning that at least some of that "badly" is because Fedora cannot ship patent-encumbered multimedia codecs.

If Flatpaks are reproducible why not build them?

Posted Jul 25, 2025 20:56 UTC (Fri) by JoeBuck (subscriber, #2330) [Link]

If stripping patent-encumbered code degrades the functionality of the application significantly, then Fedora just shouldn't publish it.

Container images?

Posted Jul 23, 2025 9:35 UTC (Wed) by aragilar (subscriber, #122569) [Link] (4 responses)

I wonder how well such a push will work when wanting to use Fedora in containers (e.g. to provide web desktops)? I note the snap-ification of Ubuntu creates may issues there (e.g. the need to replace the Ubuntu-provided snap with Mozilla's deb), and if there is no "traditional" Fedora distro (i.e. workstation becoming effectively silverblue), then I wonder if Fedora is less useful as the faster-moving rpm-based distro?

Container images?

Posted Jul 23, 2025 11:26 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

The claim is that the traditional distro isn't going away. Presumably those RPMs would still make up the base system. Only time can really tell though; it depends on how much developer interest Fedora can retain through it.

Container images?

Posted Jul 23, 2025 13:47 UTC (Wed) by rjones (subscriber, #159862) [Link] (2 responses)

For web-based desktop it might just be better to run the desktop inside of a VM. There are nice ways to integrate 'thin' virtual machines into things like kubernetes or other orchestration solutions. Running a multiple desktops used by different users/groups in containers side by side seems like a bit of a nightmare security-wise.

Silverblue is still rpm-based. It uses the same rpms as Fedora Workstation does for the most part. The difference is how they are managed to provide the "Atomic" features. And in the future when bootc becomes adopted then the OS itself is distributed as a OCI container image.

One of the things I like about the "containerized desktop" approach is that it creates a clean separation between "OS" and "Application". (Note that your OS doesn't have to be Atomic or Immutable to take advantage of containerized applications.)

Like in Networking we have the TCP/IP stack, which divides the network protocols up into layers (link, internet, transport, application). That way different layers can be swapped out without impacting too much the layers above or below it. The same application data can ride over ethernet, cable internet, etc. With the traditional Linux distro you have only two layers... "Kernel" and "Userland". Were Userland is just a tangled mush of interdependent dependencies with no real distinction between what makes a system level service vs a desktop application.

If you end up with separate "OS" and "Applications" layers then that, theoretically, should free up the OS part considerably. They should be able to make more radical changes and accelerate development at that level without expending a great deal of resources on maintain applications and their compatibility. Similar to how the Linux kernel is able to iterate separate from Linux distributions. Especially when it comes to the Desktop Environment part of the OS.

Like how many dozens of groups maintain their own version of "Firefox Browser". There has to be a different set of volunteers for each major distribution that modifies how it is built and packages to conform to their specific vision of how OS should be laid out and packaging policies. That is a lot of work put into doing things in slightly different ways only to end up with the ideal situation that there is no discernible difference at all in how the application behaves on any of these distributions. But in the end we only really need to have it packaged once.

It is a nice experience when upgrading, say Fedora 41 to 42, that all my desktop applications remained the same before as after. It is a lot less worry about some of the more cantankerous proprietary ones that I need for work, like "Zoom desktop". Dealing with small differences in OSes after upgrades is not something I look forward to on my workstation when faced with deadlines, so it is nice when the applications I use don't all change along with it.

So hopefully it should allow Fedora to be the even-more-faster-paced rpm-based distro.

Container images?

Posted Jul 24, 2025 11:51 UTC (Thu) by aragilar (subscriber, #122569) [Link] (1 responses)

Jupyterhub with k8s is the defacto standard for providing access to these kind of services, and it remains relatively easy to spin up various images with specific applications (desktop or otherwise) where they are provided by by debs/rpms. That's not true when snaps are involved. I've also seen snaps unable to handle home directories not in `/home` (which isn't unusual in more traditional unix environments). I've not dug into flatpak or appimage (so maybe they're more reliable) in those kind of environments (as typically it's easier to get apps other ways), but I wouldn't surprised if they bring along their own issues. Partly it's the underlying technologies involved, but I think partly it's a disconnect as to what different groups of users want or need from the packaging technologies.

Container images?

Posted Jul 24, 2025 21:01 UTC (Thu) by raven667 (subscriber, #5198) [Link]

While they may have some overlap in technical issues in what the Linux kernel and common desktop environments are capable of doing to support containerized desktop applications, I wouldn't presume that the bugs which snap apps face are going to be the same bugs that flatpak apps run into, as snaps are just another non-canonical technology which is only developed by Canonical that is never going to grow an ecosystem beyond whatever in-house development they can afford because their corporate culture and CLA practices inhibit collaboration with the rest of the (small, but always growing) desktop Linux ecosystem. Flatpak has had much more engineering effort put into by a wider array of better engineers than Canonical can hire, so I expect the arc to be the same as Upstart/systemd, Unity/GNOME, Wayland/Mir, etc. where eventually Canonical will get tired of paying to be different and adopt the Flatpak multi-vendor standard for containerized app packaging, maybe with their own branded frontend so they can operate a paid storefront.

Bah, Humbug (:-))

Posted Jul 24, 2025 0:41 UTC (Thu) by davecb (subscriber, #1574) [Link]

Another attempt to solve an NP-complete problem. Before diving down this rat-hole, have a peek at Russ Cox's “Dependency hell is NP-complete" at https://research.swtch.com/version-sat

For even more nerditude, see https://leaflessca.wordpress.com/2017/02/12/dll-hell-and-... It's something I've written a lot about.

--dave
(spoiler: don't work around it, make it impossible. That's been independently rediscovered three time, including by the glibc folks)

Flathub Must Improve

Posted Jul 24, 2025 2:30 UTC (Thu) by pabs (subscriber, #43278) [Link]

The stuff in the "Flathub Must Improve" section of that post is quite concerning...

Phasing out Fedora Flatpaks ... completely?

Posted Jul 24, 2025 19:22 UTC (Thu) by swilmet (subscriber, #98424) [Link]

From the blog post:

> There are important technical differences between Fedora’s Flatpaks, built from Fedora RPMs, vs. Flathub’s Flatpaks, which are usually built on top of freedesktop-sdk. But I will not discuss those, because the social differences are more important than the technical differences.

The technical differences *will* matter though (at some later point in time): does it make sense to maintain a whole infrastructure and a different way to build Flatpaks for just a few apps (the core apps that are installed by default) ? Ok these apps are important to polish, but it's doable for Fedora to use the same way to build Flatpaks as Flathub: by using freedesktop-sdk and flatpak-builder.

This would slightly duplicate the work: creating the relevant RPMs for the traditional package-based Fedora Workstation variant, plus creating the few Flatpaks for the core apps.

I think the problem of maintaining a different way to *build* Flatpaks will come in the discussion as well. As any software, it requires maintenance and has its own bugs.

Single point of failure?

Posted Jul 24, 2025 21:59 UTC (Thu) by tlb (subscriber, #178072) [Link]

While I use Flathub on my openSUSE installs I am still concerned that Flathub could become a "single point of failure" for the entire desktop Linux ecosystem if we all depend too much on it. Are the maintainers ready to take on that responsibility? Is there a way to clone and reproduce the Flathub repository in case it goes offline or is compromised in some way?