Choosing between Flatpak and RPM

Ask Fedora
, , ,
1

I was wondering if someone could be kind enough to enlighten a new Linux user on the practical differences between installing an app as a Flatpak vs. installing as an RPM package. I’ve come across these two types of downloads while browsing apps on Fedora’s Software app, and I’ve seen that what’s offered as download options for any given app there can vary (some just offer just one Flatpak, some offer a Flatpak and an RPM, some offer two Flatpaks and an RPM, etc.) I’ve also noticed that the Software app’s safety rating can vary between the different download options for an app. (A brief rundown on the Software app’s safety rating system/criteria would be nice too, if possible.) In short, I don’t know how to pick between the two, or whether one is generally recommended over the other.

I’m going to wager a guess that one isn’t completely superior to the other in terms of things like stability, performance, and security, otherwise they wouldn’t both exist.

I’m also going to bet that other factors are involved on which one is safer, such as the exact source you get an app from (e.g., gedit as a Flatpak from registry.fedoraproject.org vs. an RPM from fedoraproject.org vs. a Flatpak from dl.flathub.org are probably all different in some way or another.)

I haven’t installed many apps so far since I’m just getting started with a fresh install of Fedora Workstation - I can just name Visual Studio Code and GitHub Desktop, which I’ve installed as RPMs using instructions on their respective websites instead of using the Software app. I’m itching to ask how much any of this matters before I proceed with setting up anything else.

I guess there’s also the related question of whether I should bother using the Software app to install anything or if it’s better to directly install apps from their respective official websites.

5 Likes
2

First: You are on Fedora Workstation, where the system packages are installed as individual rpm packages. (This is different on rpm-ostree Fedoras such as Silverblue.)

rpm packages that you install in addition are installed in the same way and the same “place”. Thus they can be well integrated in the system but/because they are not separate from the system packages; if they depend on other packages those get installed automatically (as separate packages, not separated from the others). This has advantages and disadvantages and used to be the only way (on Fedora, unless you compile yourself, …).

flatpaks are miniature containers. They specify their required permissions and are isolated otherwise. Thus they are separate from the system packages and from each other; integration and separation depend on how the flatpak is “packaged”; if they depend on other components they typically bundle them in the flatpak. This has advantages and disadvantages and is the “only” (preferred) way to install “apps” (graphical, integrated) on rpm-ostree Fedoras without hampering the rpm-ostree benefits.

Independent of that is the question of sources:

Fedora flatpaks are built from the same sources as Fedora rpms and follow the same packaging guidelines. (Versioning is different, and features can differ.) You can trust them all the same. So far, only a small fraction of Fedora rpms packages is available as flatpak.

Flathub is the main “source” of flatpaks, with huge quotes: It’s just a “download site” in the sense that flatpaks are created and checked by whoever uploads them there. There is no uniform standard and no uniform source of trust. This is similar to rpms which you get “from somewhere”, the difference only being that in this case its clearer “where they are from”. On flathub (which is presented as one “source” in the software center) you would have to check there individually. This also concerns the separation that I mentioned above: flatpaks may be isolated, but not if they require too many permissions.

If “rpms from somewhere” come with a rpm repo definition and you activate that repo then you will get updates automatically, otherwise you won’t. Flatpaks from flathub (or any flatpak “repo”) come with updates.

So, personally, on a system like yours (Fedora Workstation), I would in this order:

  • generally prefer Fedora rpms (availability, integration, trust)
  • use a Fedora flatpak if you need a newer version
  • use a “vendor” rpm repo if you trust them (say, google-chrome repo if you trust google)
  • use a “vendor” flathub flatpak if you trust the vendor (say, signal)

The last two probably on equal footing. I would avoid “just rpm from somewhere” without updates.

And there’s nothing wrong with getting a flatpak just to try it out and uninstall it again, that’s often easier than with rpms (because of dependency management/removal).

7 Likes
3

So I’m getting a few main points from this, please correct me if I’m wrong:

  • RPM packages are more integrated into the system. Has pros and cons. I’m guessing that dependency management can potentially get more difficult if you have a lot of RPMs installed that all share dependencies.
  • Flatpaks are miniature containers with varying levels of isolation (depending on the required permissions) where any dependencies are already bundled into the container and don’t have to be installed to the whole system. Also has pros and cons.
  • Generally speaking, RPMs and Flatpaks sourced from Fedora itself (i.e. from the fedoraproject domain) are likely going to be safe. If Fedora doesn’t offer a release of an app, look for a trustworthy vendor repo that provides updates. Try to avoid blindly pulling Flatpaks and RPMs from “just wherever” (this just seems like common sense, honestly.)
  • Flatpaks may be handy for sampling an app since they’re often easier to uninstall without breaking something else.
  • Flatpaks tend to be a newer version of an app? Why is this?
4

That is typically handled behind the curtains, at least for Fedora rpms. But it can happen that a Fedora rpm update needs to wait (to be applied) until, say, a rpmfusion package which depends on a Fedora package is made available to match the Fedora update.

E.g., you don’t have to wait for an update to a depending package. On the other hand, you may have outdated “parts” in some flatpaks without you noticing: a security fix to a library is not propagated through the library rpm, but every flatpak has to be rebuilt.

That assumes that you trust Fedora :slight_smile:

Yes. It’s possible with rpms, too, but feels easier with flatpaks.

Not necessarily, but:

In Fedora, we push updates to the development (non-)release (called rawhide). Depending on severity etc., we may push it to the current release (38 right now) and rarely to the one below (37), never to end-of-lifed releases (36 and below). Fedora flatpaks do not form “releases”, rather the packager decides which Fedora branch to build the package from. Right now this typically is Fedora 39 (which is in beta) or Fedora 38. You can use that flatpak on any Fedora.

For non-Fedora flatpaks: Since they are not distro-specific, they are often the preferred distribution method for “upstream” (creator of the app etc) and updated regularly by them. They are not bound by Fedora’s packaging guidelines and can provide newer versions, but don’t have to, of course.

Also, there is for example flathub-beta for test versions and the like. We have similar things for rpms (such as updates-testing, rawhide, copr), but flatpaks are easier for non-technical users, I would say, because you can’t mess up your base system that easily.

2 Likes
5

I suppose I do, otherwise I wouldn’t be using their operating system. :laughing:

Jokes aside, I’ve appreciated your insight.

6

So can you consider Flatpak as something of a more “universal” distribution method that’s not specific to any particular Linux distribution(s), whereas RPMs are more specific to Fedora (and other related Linux distros)? Is that why Flatpaks come with their own copy of any dependencies: so that they’ll work on any Linux distro?

7

Also, would it be relevant to ask here why the Software app warns that so many of the apps offered there (even stuff sourced from Fedora) are “unsafe”? In particular I’m commonly seeing warnings about legacy windowing systems and having full system read/write access, both on Flatpaks and RPMs, but it seems the safety rating can vary even when a Flatpak and an RPM of an app come from the same source.

Is the Software app’s safety rating something to be taken at face value/particularly seriously? Cause if so, that eliminates a lot of downloads offered on the app on the basis that they’re unsafe.

8

Let us say it’s a work in progress (and/or one of GNOME’s interesting design choices). The safety rating verges on the philosophical, e.g. one could argue that only LFS systems vetted by their administrator might warrant a “Safe” rating, but these don’t have any use for software centers and even then, you can’t be 100% secure.

If you have time to kill, read through these two tickets [1] [2] I’m fairly certain there are more.

  1. ↩︎

  2. ↩︎

9

That’s kind of the vibe I got. From skimming over those two tickets, I saw a lot of debating about what should be considered “safe” or “unsafe”, or, even more broadly, the semantics about what those kind of words (safe, unsafe, trusted, privileged, etc.) should even mean in the first place.

10

Yes. There are some basic interfaces that the flatpak environment guarantees to all flatpaks (no matter which distro). Then, there are so called run-times which are flatpaks consisting of typically used dependencies, without any “apps”. An app flatpak can then depend on a run-time which needs to be installed only once (not each time for all apps which need it). For example, firefox in flathub:

        ID: org.mozilla.firefox
       Ref: app/org.mozilla.firefox/x86_64/stable
      Arch: x86_64
    Branch: stable
Collection: org.flathub.Stable
   Runtime: org.freedesktop.Platform/x86_64/22.08
       Sdk: org.freedesktop.Sdk/x86_64/22.08

Firefox in fedora:

        ID: org.mozilla.Firefox
       Ref: app/org.mozilla.Firefox/x86_64/stable
      Arch: x86_64
    Branch: stable
Collection:
   Runtime: org.fedoraproject.Platform/x86_64/f38
       Sdk: org.fedoraproject.Sdk/x86_64/f38

If you install the latter on any distro, the run-time will bring “enough of fedora” along with it for this to work. Same with the distro-agnostic freedesktop runtime. [And for some reasons those two code markups look different in the preview, let’s see …]

11

GNOME Software is providing SW safety rating like so (second “box” from the left):

image
image876×186 15.1 KB

E.g., for GNOME Connections all three sources (RPM, Fedora flatpak, Flathub flatpak) are green (safe).

However safety is different for Easy Effects - green for RPM version and amber for Flathub flatpak. Clicking on the SW safety “box” will reveal more information, e.g.:

image
image936×1030 83.2 KB

Normally less safe versions are OK for normal use, you just have to check that additional information to make an informed decision, e.g., lower safety rating is given to apps using older versions of windowing systems or having access to all files of your home dir, which might be normal if that’s, let’s say, a drawing app which creates and edits files.

2 Likes
12

The short of it is that both flatpak and rpm are supported regardless of whether you’re running Workstation, Kinoite, Silverblue, etc. Some of it comes down to personal preference and convenience. Flatpak are generally a better experience on Kinoite, Silverblue, etc. than rpm, but you can definitely still install stuff with sudo rpm-ostree install and there are things that don’t exist in flatpak.

Another reason is that versions of things and bundled libraries might differ, and this is especially true for 3rd party stuff. Slack doesn’t officially support Fedora any more via RPM, but the non-official flatpak exists. Zoom does support Fedora via rpm, but the unofficial Flatpak might behave better. There’s not a right or wrong way here. It’s your system and if one method works for you, then use it.

So, basically, you have options. Between Fedora’s repos, RPMFusion, and Flathub, there’s a whole lot of the software world right at your fingertips.

1 Like
13

“You can” not always means “you should” :wink: With immutable Fedora variants it is recommended to layer only system-wide packages (e.g., system drivers/sub-systems - nVidia GPU drivers, OpenVPN support and similar). More on intended ways of adding SW (layering VS flatpak VS toolbox) to immutable variants of Fedora can be found here - Getting Started :: Fedora Docs.

14

Nah, it’s your system, do what you want. Both are supported. I use a bunch of rpm-ostree on my Kinoite box and the vast majority of it isn’t available in flatpak. I also use flatpak and toolbox on my Workstation machines. Use whatever tool seems the right tool for the job for you.

1 Like
15

Of course ! If one is able to rebuild custom kernels, knows how to compile apps from sources, debug and patch issues - such person can do whatever he/she needs with HW and SW in his/her possession :smiley:

16

This is a misnomer, the immutability or non-immutability is secondary. What the system is is image based, so that image that comprises the released image base is the same on whatever machine it is installed. It is a system that is reprovisionable and that has inherent anti-hysterisis.

Since when? This is bad advice. If there was no intent of layering needed, then why bother use rpm-ostree? It’s supporting library (libostree aka ostree) can handle the image based work and the three way merge that builds the local image. Layering has a role on these types of systems and not limited to system kernel modules or such. I agree with @vwbusguy on this point, it’s your system, do as you please.

1 Like
17

By default the system operates in pure image mode, but package layering is useful for things like libvirt, drivers, etc.

Good examples of packages to be layered would be:

fish: An alternative Unix shell

sway: A Wayland tiling compositor

libvirt: The libvirt daemon

Again, with your system you can do anything. Period. But things normally work better (safer, more stable, etc) if used for intended purposes and as per authors’ recommendations. For Silverblue and sister distros layering, toolbox and flatpaks as separate SW addition methods exist for purpose. You can ignore that and do ostree layering for everything and that will work just fine, probably. But that’s not how it was planned to be used. And if you have good justified argument (or more) for your “This is bad advice” - I’m ready to hear it.

19

Again, I think you’re making presumptions here, have you spoke with the original developers around Silverblue? I don’t think they would agree.
It is bad advice to state that you shouldn’t do ‘layering of packages’ because it’s preferable to do ‘installation by flatpak’ simply because there is some misguided perception that ‘layering’ is somehow going to lead to the destruction of your system. I was an early adopter of Silverblue when it was named Atomic Fedora, and layering was always considered a plus, especially when you look at some of the alternatives using libostree that are out there. Layering is another tool at your disposal on an Image based :fedora: system that enables greater flexibility to the system owner who still wants the security and stability of an image based system. Period.

20

It’s interesting to see where this thread went. Just to recall: Someone on Fedora Workstation asked for advice on installation paths (in the sense of “ways”, not file-system). I’ll turn off “alerting” (as I’m sure the OP has meanwhile).

Just this bit on the dreaded layering mill: layering adds layers on-top of the rpm-ostree image (duh!). As a consequence:

  • Your system is not running “the same system image as everyone else” any more.
  • Your actual tree has to be rebuilt (new base layer plus your layers) on every update.

Now, depending on why you use an image based system, this may or may not mean that it still fulfills your purpose.

21

You think. So that’s an assumption, right ? :wink: I do not presume, I read docs, watch how people (including creators/maintainers) are using SB. E.g., here Matthias Clasen is talking about advantages and disadvantages of package layering. Jorge Castro has multiple videos on use of SB, this video in particular talks about package layering as well.

I never said that. What I said that there are 3 ways of adding SW/apps to the SB are meant to achieve slightly different goals as they add SW/apps differently. Those ways also having its advantages and disadvantages, thus should not be used interchangeably or one of those ways for all cases, although technically that might be possible. Again, you (or anyone else) are free to do with your systems anything you what, but saying that package layering is equally OK to manage all types of your SW on SB is misleading.

In order not stay off topic here, I stop arguing now :smiley: Peace!