2 packagers but 3 packages? [LWN.net]

2 packagers but 3 packages?

Posted Mar 3, 2025 7:30 UTC (Mon) by marcH (subscriber, #57642)
Parent article: Fedora discusses Flatpak priorities

Sorry if I read too fast but... how come there are three different packages available? No matter what their format is.

As usual, we have two potential "packagers":
- upstream
- the Linux distribution in use

Often less than two when upstream is not interested in packaging. Or when the distro does a quick and dirty job that does not really count (for instance: when a single person packages 100s of packages?)

So, a grand maximum of two "packagers". So how come we end up with three different packages? Are Fedora packagers not talking to each other?

The most time-consuming thing is not compiling and packaging, it's QA: _testing_ and making sure everything works, making sure known vulnerabilities are patched, reviewing changelogs, establishing a trust relationship with upstream etc. No Linux distribution has the bandwidth to do this twice (I bet: not even once sometimes)

to post comments

QA and trust

Posted Mar 3, 2025 7:31 UTC (Mon) by marcH (subscriber, #57642) [Link]

The debate about priorities seems to also sweep quality under the rug. No matter who packages and how, the most important is: does it work; which bugs and vulnerabilities there are. That's the most important part of the user experience, much more important than the packaging approach and technology. So, package priority should not be hard-coded to the packaging technology, that's the tail wagging the dog. Package priority could have a default but that default should be easy to override on a per-package basis.

> Users want Flatpaks created by upstreams, but are confused by the way they are displayed in GNOME Software. He recommended that the priority be changed to display software from Flathub first, then Fedora Flatpaks, and finally Fedora RPMs.

In any case, it should always be crystal-clear which software comes from where. Not just for deciding which bug tracker is relevant but also for obvious trust and security reasons. No user interface should ever hide software provenance(s) and make installation so easy it feels "magical". Users should be invited to pause and think before installing and running less common software that isn't "core" and is not used by everyone else. Cause it very likely had much less scrutiny and is then more likely to have bugs, vulnerabilities and backdoors. It's easy to make fun at how time-consuming and painful it is to install software on Windows, but this also forces users to be a bit more conscious of what they are doing. There is a middle ground/sweet spot somewhere.

https://queue.acm.org/detail.cfm?id=3344149 "Surviving software dependencies" - a lot applies exactly the same here.

Let's try to move the software industry past its teenage years.

2 packagers but 3 packages?

Posted Mar 4, 2025 0:59 UTC (Tue) by AdamW (subscriber, #48457) [Link] (9 responses)

Because two are flatpaks and one is an RPM.

1. Fedora RPM
2. Fedora flatpak
3. Flathub flatpak

The Fedora flatpak is built from the Fedora RPM.

2 packagers but 3 packages?

Posted Mar 4, 2025 4:09 UTC (Tue) by marcH (subscriber, #57642) [Link] (8 responses)

> The Fedora flatpak is built from the Fedora RPM.

Thanks - but why does Fedora do that, what is the point? Please feel free to shame me and point me at the part of the article I missed.

2 packagers but 3 packages?

Posted Mar 4, 2025 6:56 UTC (Tue) by zdzichu (subscriber, #17118) [Link] (7 responses)

The point for packaging an RPM is obvious, I hope. For the flatpak, there are experiments with immutable distributions (Fedora variants Silverblue and Kinoite). Immutable distributions are cumbersome to add software to, but this is alleviated by having apps in flatpaks. If you have to provide a app in such format, it is most obvious to build a flatpak from an existing RPM. It is (in theory) already audited, integrated and follows distribution lifecycle.

2 packagers but 3 packages?

Posted Mar 4, 2025 8:19 UTC (Tue) by marcH (subscriber, #57642) [Link] (6 responses)

> Immutable distributions are cumbersome to add software to, but this is alleviated by having apps in flatpaks.

Thanks. So, immutable variants never have 3 packages because the RPM is not compatible with them. Great.

This still does not explain why the Fedora RPM and the Fedora Flatpak are _both_ available on the regular, "mutable" Fedora.

2 packagers but 3 packages?

Posted Mar 4, 2025 9:43 UTC (Tue) by farnz (subscriber, #17727) [Link] (5 responses)

There's two reasons (one good, one that probably ought to be fixed in the long run and is marginal to begin with) to have both a Fedora RPM and a Fedora Flatpak:

Flatpaks are sandboxed in ways that RPMs just aren't (at least for now). As a result, if you're uncertain whether a given piece of software is suitable for your needs, a Flatpak is marginally safer.
If you're running Fedora Workstation, but want to work out whether Fedora Silverblue would work for you, you need to swap out RPMs for Flatpaks to confirm that the same software packaged as a Flatpak works for you despite the sandboxing.

And the reason to have Fedora Flatpaks as well as upstream is that Fedora promises that its software meets a set of policies; Flathub (and other sources of Flatpaks) don't promise to meet Fedora policies, for fairly obvious reasons.

2 packagers but 3 packages?

Posted Mar 4, 2025 21:23 UTC (Tue) by marcH (subscriber, #57642) [Link] (4 responses)

Thanks!

> Flatpaks are sandboxed in ways that RPMs just aren't (at least for now). As a result, if you're uncertain whether a given piece of software is suitable for your needs, a Flatpak is marginally safer.

OK, so if Flatpaks are generally better then don't offer the corresponding RPM available when a tested Flatpak is already offered.

> If you're running Fedora Workstation, but want to work out whether Fedora Silverblue would work for you,...

That's useful for developers, packagers and testers. Not for "plain" users. The ability to try both is great, but both should still not to be offered by default.

Thanks to everyone who answered I'm starting to suspect the root problem/original sin is really this: _it's not possible to make decisions on a per-package basis_. In some cases the Fedora RPM should be the only Fedora package offered. In other cases, the Fedora Flatpak is available and better and it should be the only Fedora package offer. But the package management software is not flexible enough to support such decisions and fine-grained configuration. That sounds like the big shortcoming affecting the user experience.

Developers should always be able to opt-in and be offered everything that is available. But regular users should not have to make choices like this. Plain users pick a Linux distribution expecting a cohesive whole where they generally do not have to think and combine packages and versions themselves.

Or, maybe Fedora is just a distribution focused on developers and not very good for plain users. Fine by me! I'll keep using it anyway.

2 packagers but 3 packages?

Posted Mar 4, 2025 21:39 UTC (Tue) by pizza (subscriber, #46) [Link] (1 responses)

> OK, so if Flatpaks are generally better then don't offer the corresponding RPM available when a tested Flatpak is already offered.

IIUC Fedora flatpaks are always built _from_ the RPMs.

2 packagers but 3 packages?

Posted Mar 5, 2025 0:24 UTC (Wed) by marcH (subscriber, #57642) [Link]

> > OK, so if Flatpaks are generally better then: do not offer the corresponding RPM available when a tested Flatpak is already offered.

> IIUC Fedora flatpaks are always built _from_ the RPMs.

So?

Does that mean the flatpak can only be safer hence better? Then hide the corresponding RPM.

In practice, some unexpected things always go wrong and I bet some flatpaks can fall... flat. Couldn't resist, sorry. Then, hide that particular flatpak from non-developers.

In any case some level of per-package flexibility is required.

2 packagers but 3 packages?

Posted Mar 5, 2025 8:23 UTC (Wed) by farnz (subscriber, #17727) [Link] (1 responses)

Flatpaks are better on the assumption that the sandboxing does not block anything you want it to do - but that's a big assumption. For example, I tried running on Silverblue, but found that the way the GNU Emacs Flatpaks behave (both Fedora and Flathub) was incompatible with my workflows because of the sandbox (albeit I've since switched away from Emacs)

But (as a counter), I'm happy with LibreOffice from Flatpaks, because the sandbox doesn't get in my way. I'm slowly removing non-Flatpak packages and replacing with Flatpaks, with the intent to switch over to Kinoite (because I keep coming back to preferring KDE to GNOME) once I've reduced my system to one where all applications I use are Flatpaks.

That said, your software setup should only show you one of the 3 options at a time; I've just checked KDE's Discover, and there's a button at the top-right to choose a source - either "Fedora Linux", "Fedora Flatpaks" or "Flathub", with a different icon for "Fedora Linux". It also has a default choice it makes, which can be set by the distro; I believe that 99% of the issue is that Fedora's default was set to prefer Fedora Flatpaks over Flathub, and Flathub over RPMs, and if it were configured to prefer RPMs or Flathub, the issue would be less serious.

2 packagers but 3 packages?

Posted Mar 5, 2025 14:31 UTC (Wed) by madscientist (subscriber, #16861) [Link]

Agreed; the GNU Emacs flatpak wasn't useful to me due to the sandboxing. On the other hand, I use Gnome Evolution via flatpak and it works great for me.

However, the GNU Emacs snap (which uses snap's "--classic" option) allows me to use up-to-date GNU Emacs on my ~5 year old distribution (which I can't upgrade for $Job IT reasons).