Layering considered.. fine?

Project Discussion
, ,
1

I’ve seen a couple of times a variation of the following argument:

You shouldn’t add too many layers using rpm-ostree, because it will cause “problems” (instability, issues, weirdness, etc)

I don’t think this is true - or, at least, if it is true, I don’t understand why it is true.* My understanding is:

  • All Fedora RPMs are designed to be installed alongside each other on the corresponding release of the Fedora (or, refuse to install alongside incompatible RPMs, for example), and if one doesn’t then this will be (and has been) considered a bug, and fixed.
  • The immutable variants of Fedora are essentially a collection of RPMs “installed” to an ostree image, just like how the mutable variants are a collection of RPMs (except, installed directly to disk). These images constitute the “base” of the OS.
  • rpm-ostree “layers” the changes to the base image (all the same packages that would be installed on a mutable variant), uses that to create a new ostree image, and stages that image for you to reboot into.
  • All Fedora packages are expected to install on immutable variants of Fedora, and if one doesn’t then this will be (and has been) considered a bug, and fixed.

As such, it seems to me that if rpm-ostree is doing it’s job correctly (which it seems to - it’s very reliable in my experience) then there is no reason to expect an immutable variant of Fedora with many layered RPMs to be less stable/error-prone/“weird” than a mutable variant of Fedora with the same RPMs installed. Should it?

Note: I am keenly aware that there are often better ways to install things on immutable variants of Fedora (luv a Flatpak, luv a container) - but those aren’t universally better, and often the best decision (or, the best decision for someone that understands RPMs but not yet containers) is to “just layer it” - either until the other options catch up, or until the user’s understanding catches up.

My view (which I am seeking to challenge by making this post) is that rpm-ostree is reliable enough for most users to make the switch from mutable variants today - yes, use Flatpaks and toolboxes where they make sense (or, where you can make sense of them), but for anything that doesn’t work (or, doesn’t work reliably), just layer it.

If not, why not?

*for Fedora-sourced RPMs - outside of the Fedora repositories “weirdness” may happen due to those RPMs being tested on Fedora but not Silverblue/Kinoite/CoreOS/etc, which is also true of RPMs tested on RHEL/CentOS but not Fedora Workstation and has been a long-running issue with packages not sourced from the distribution on any OS.

1 Like
2

I layer with abandon and don’t regret it at all. The only weirdness I ever encountered was a result of my own actions, and it was also early on in Silverblues existence (F27 or so). Things have changed a great deal from that time and everything is more stable.

2 Likes
3

Never had a problem with layering personally. There’s still the DNF portion of rpm-ostree to check dependencies so I don’t see why there would be an issue.

2 Likes
4

So far I only found tldr that would not work after installing it in the toolbox. And tilix would not run properly from the Flatpak, so I layered them. tldr, fastfetch and tilix, that’s it.

I still don’t get this chattering on the forums about not cluttering up the os-tree, but I only have 3.

1 Like
5

This came up again, this time in regards to using override remove, specifically in relation to Firefox (which is part of the base layer). Some people want to use the Flatpak’d Firefox, and having it installed as an RPM as well leads to weird things.

The current recommendation (in the docs) is to leave it installed, and hide it - which I would consider to be really hacky. I expanded on this here but this is the gist:

It’s not so much that I have a use-case for this not working - rather that I consider it a messy, manual solution that relies on the user remembering that there’s a version of Firefox installed (in the base image) and that they manually patched it out (which can be annoying e.g when hunting down bugs, only to find that somehow you’re using the RPM version of Firefox again…). With the override approach you can see, plain as day in the rpm-ostree status output, that Firefox is removed - and it is actually removed!

(A user on the subreddit actually tripped over this, and I recommended just overriding the package instead of playing whack-a-mole trying to subvert the package manager).

In my view, the unique proposition of Silverblue is that you get to leverage the Fedora RPM ecosystem while still benefiting from an immutable base to work on (that is, the base image, overrides and layers combined).

These hacks present worse alternatives, in my view, because they get forgotten about - nothing is tracking that you manually hacked out Firefox from being visible, for example, in the same way as rpm-ostree is.

6

Note that we’re removing most of those apps in Kinoite F39 (see: Issue #13: Build Flatpaks for KDE Apps - SIG - Pagure.io).