View source for Pros and cons of package layering with rpm-ostree

__NOTOC__
Fedora Atomic Desktop has a curated OS deployment package which is applied as an atomic image. Atomic Desktop has quite a few benefits over non-atomic which I quite like, such as being able to easily roll back to previous OS deployments, pin OS images as backup revisions of the OS, etc. It is much harder to brick the Atomic Desktop, as if you break the system you can simply roll back to the previous deployment. Previous deployments also retain previous copies of the /etc folder, so even config changes get rolled back, which is extremely convenient and makes the OS feel much less brickable.

If you want to install rpm packages, these have to be layered over the top of the base image. To do this you can use a tool called rpm-ostree, which replaces dnf for some commands (but not all of them). System updates then have to re-layer the packages again as part of the update, which is inefficient and can cause dependency issues. Users of Atomic Desktop are therefore supposed to avoid layering.

Instead, you are supposed to install user-level packages by using Distrobox/Toolbx/Homebrew/containers, or you are supposed to use Flatpaks or AppImages.

Here's a breakdown of why you might want to layer packages, why you should avoid layering packages, and a potential workaround (sadly not for the layman).

=== Reasons to use package layering ===
* Some software is only available via the package manager, so you are forced to layer it if you want to install it.
* Some software is only available via an AppImage or via the package manager, but AppImages don't have automatic updates, whereas packages do. AppImages are also much slower to open than the version included in the rpm package. The rpm package is therefore probably a better option in this case.
* Some software simply makes way more sense to be installed directly into the OS, either because it effectively acts as a core shared OS component (e.g. EasyEffects, FluidSynth) or because it should really have come with the OS to begin with due to being a basic tool and it makes no sense why it's missing (e.g. htop).
* Sometimes flatpaks are inferior to the versions included in the package manager (e.g. the LibreOffice flatpak is missing the kf6 package and thus uses the wrong filepicker)

=== Reasons to avoid package layering ===
* Package layering is inefficient because you have to reapply layered packages onto each newly downloaded base image.
* Package dependency hell when trying to install or update packages and/or update the OS base image.

=== What is package dependency hell and why does it happen? ===
rpm-ostree isn't very smart, and appears to be unable to backdate the dnf repository contents to match the image you're using. Because of this, it's very likely you will end up in dependency hell where you are trying but failing to layer packages (if not immediately, then it can hit you when you try to install or update packages and/or the base image in future).

Dependency hell example:
* The version of python3 in your base image is 3.14.2
* You choose to layer python3-devel, it installs python3-devel version 3.14.2 which matches the python3 in your base image
* Fedora repositories update python3 to 3.14.3, but the base bootc image still has 3.14.2 baked into it
* You try to layer nodejs
* You can't install nodejs because rpm-ostree tries to update python3-devel to 3.14.3 when it builds the new image, which is incompatible with the 3.14.2 in the base image

The correct solution would be to pretend all package versions released after the base image was created don't exist, and to therefore keep python3-devel 3.14.2, because that was the latest version at the time of the base image's creation. Sadly, rpm-ostree seems like it wasn't designed to do this. This makes dependency hell essentially inevitable with layering (despite the fact that it could have easily been avoided).

=== Creating your own bootc image ===
To avoid most of the disadvantages of layering, you can use the image-building tools to build your own image, and then bake the packages you find important into the image. This mostly avoids the dependency hell and the requirement to reapply the layered packages (since they are no longer layered). You obviously might want to try layering the package first (to make sure it does what you expected it to do) before you add it to your image.

Instructions are here: https://github.com/ublue-os/image-template