I’m setting up my very first Fedora installation, namely F42 Workstation. I’m puzzled by the numerous options for software installation. I believe I understand the basic difference between RPMs and flatpaks, but why are there typically two different flatpaks, one from Flathub and the other from the Fedora Project? I would guess that latter is in some way customized and likely usually what I should install, although it may entail a bit more risk in that the Fedora version may lag the Flatpak version for updates (though I’ve read bad things about the Firefox flatpak and am glad to see that the RPM has been installed by default).
When it comes to Thunderbird, two versions show up in Software:
I tend to not use Snaps, and install as many applications from Fedora, falling back to a flatpak from Flathub if necessary.
In this case specific I’d install BetterBird anyway, and the issue would be solved, but generally I prefer the latest released version on the basis that the likelihood is that it gets more attention and is likely to be packaged more frequently as updates are rolled out.
If you are not on Silverblue or an Atomic distro which only uses Flatpaks, then stick with the RPM and ignore Flatpaks and containers for the forseeable future.
The single exception is when you absolutely need a software that is only packaged as a Flatpak.
My rationale is that this will minimise updates and keep things as simple as possible for future troubleshooting.
I’m not sure what it means to “minimise updates“? And in my humble opinion the easiest troubleshooting experience is when the system is clean and in the form intended by developers, in which flatpaks help a lot, since apps are installed not in directories controlled by dnf. Also, flatpaks are just really useful and a very nice tool.
I often struggle with this too, Ken. Just think, we could even have Snaps as a fourth option! (no hate against Snaps, it’s just that there are so many package format options now!)
In case it’s helpful to you, this is generally how I choose what package format to install in order of precedence:
How does the original author(s) of the software distribute it? If I can get an RPM or Flatpak directly from them, I will use that. VS Code is a good example of this, they offer an RPM, so I use that over the Flatpak.
If the author(s) don’t officially support RPM or Flatpak, then I’ll usually check to see if the Flathub version is at least “verified” (get to this in a minute) and if it is, I’ll use that.
If I run into any issues with the Flathub variant, it’s not verified, or my only option is the Fedora Flatpak, I will just use the Fedora Flatpak.
Regarding Flathub’s verification system:
It’s always felt a little misleading to me because it defines a “verified app” as being:
Verification is the process by which Flathub and developers confirm that an app is published by the original developer or an authorized party.
Which can, in some cases, just mean the original developer gave the green light to some other party to re-package their app as a Flatpak. On paper that’s fine, but to me I want the application to be packaged by the original author(s) whenever possible. However, in the current Linux app ecosystem that’s not realistic and I accept that.
Let’s start from the beginning: RPM is the traditional packaging format of Fedora. Flatpak is a newer packaging format that relies on container/sandbox technologies and provides a set of runtimes for applications to depend on to be more distro-agnostic.
Because of the sandboxed nature, Flatpaks are the preferred format for Fedora’s Atomic (immutable) distros like Silverblue and Kinoite (you can still layer RPMs, but that should not be the first choice). And since Fedora Atomic for legal reasons cannot enable Flathub by default, Fedora provides their own Flatpak remote, which contains applications repackaged from the Fedora RPMs. This means that these Flatpaks are basically identical to the RPMs, with the same limitations such as limited codec support.
And then there is Flathub, which is a distro-independent Flatpak remote, which provides some Flatpaks that aren’t in the Fedora remote or Flatpaks with different features (e.g., AFAIK OBS on Flathub has better codec support than the one from Fedora).
In the case of Thunderbird, the version on Flathub is maintained by the Thunderbird developers themselves and is currently version 140.4.0 ESR, while the Fedora version for a really long time was 128 ESR. There are a number of threads here complaining about the slower update pace of the Thunderbird RPM.
Personally, I like the self-contained nature of Flatpaks, especially when trying a new software, so that it doesn’t litter its files all over my ~.
I think he means minimize the actions/tasks that consists of updating packages. Namely, if all of your packages are native (RPM) installed through DNF then one would only need to “dnf update”.
When you introduce the flatpaks then you will need to also consider updating each flatpak - because this doesn’t occur by default (although flatpak itself should be updated) with DNF.
Although, I do understand and agree with your sentiment. That is when the flatpak is actually released/packaged by the Devs - But that’s not always the case on Flathub; or specifically through the Fedora flatpak repo. which is what OP was referring to.
I had thought that sandboxing gave flatpaks an edge in security over RPMs for most apps (Firefox being a notable exception, for reasons I do not understand). Is that wrong?
Because they have an edge. Flatpaks are sandboxed (including Firefox flatpak, its completely fine to use). Compared to that, rpm packaging have access to everything it wishes.
Unless you install a funny rpm from the internet, which then turns out to be a virus and your whole computer is compromised. With flatpaks the risk isn’t so extreme, since they don’t really touch as many things.
I think the short answer here is that everyone really should really pay attention to what they’re installing from where and the risks involved and how it interacts with their usecase.
A funny flatpak easily circumvents the sandbox. One can spot --talk-name=org.freedesktop.Flatpak or that it can aquire “Arbitrary permissions” in the UI but it’s not necessary clear to someone less familiar with flatpak.
Of course, no solution is perfect (in this case in terms of security), but my point is that flatpaks get a better starting point, since there is actually something confining them in the first place, and in the future maybe all those sandbox holes would get patched (at least that’smy wishful thinking). With rpm something like this isn’t really possible, since installing alone requires root access. Meaning, it can access to virtually everything by design.
(no hate against Snaps, it’s just that there are so many package format options now!)
