I’m still relatively new to atomic desktops and learning. In this documentation, it is explained how dnf isn’t available in atomic desktops and it is required to use the toolbox environment in order to use it. This page also gives the example of the fish shell as a good candidate for a layered installation via rpm-ostree which requires a new deployment of the base (and a reboot).
Now I wonder, in the macOS world, they have an immutable base for quite a long time now, and various package managers just work, such as brew, macports and pkgx. They are all installing things outside of the base image, for example in locations such as /opt/, /usr/local/ or inside the home directory. They typically add those paths to the PATH env variable for the system shells. I am able to install development tools and the fish shell this way without really having to think about it, it kind of just works.
Could dnf be setup in atomic desktops to do something similar? Or what makes this work in macOS but not in Fedora?
You can use Homebrew on Fedora FYI. It even comes preinstalled in some unofficial variants of Fedora Silverblue, like those by Universal Blue.
The short answer for why this works, but dnf doesn’t, is that Homebrew installs in /home/linuxbrew/.linuxbrew/bin while dnf usually installs in /usr/bin (I think), which rpm-ostree already installs to.
It is theoretically possible to rebuild all rpm packages to install in, say, /opt/dnf, but I don’t think it’s a trivial undertaking.
You may also look into using Nix, which installs in /nix.
I see. What bothers me is that the current recommendation to use toolbox and rpm-ostree is so much less convenient for end users than simply being able to use dnf as usual. I wish there was a way for users to not have to deal with this level of complexity. But I definitely don’t comprehend the amount of changes required to have dnf do that.
The idea is that toolbox and even rpm-ostree layering is meant for advanced (or not-so-novice) users. GUI apps are meant to be installed as Flatpaks, so regular users might not even need to go to the CLI, maybe except for installing drivers from rpm-fusion (e.g. for NVidia GPUs, older Broadcom wireless chipsets etc).
While toolbox is presented as a solution to install CLI apps, I consider it’s a proper tool for development and testing purposes, but not so much for regular usage, given that updating images is not officially supported (though possible via dnf upgrade).
Layering via rpm-ostree install is actually quite all right to be used, if the intention is to have a few apps installed as RPMs, but less so if one would do such installations multiple times a day, given the overhead in installation time.
There’s a paradigm shift one has to get used to, and there are trade-offs. I have also started with Fedora Workstation, loving the power of dnf, but then switched to Silverblue, got accustomed with the image-based systems, and now I wouldn’t switch back to traditional Fedora. My systems never fails in upgrades, which take place seamlessly, without user intervention. Even upgrades between major versions go as smooth as possible, with only a couple of commands (or clicks) needed, then carrying on with the work as usual, then rebooting into the new environment.
But even in Fedora Workstation, it seems to me that dnf could benefit from separating system installed packages and user installed packages. For example if I install the fish shell, it is placed in /usr/bin/ in the middle of a plethora of other system tools.
Instead, dnf could offer options as to where it should install packages. Maybe the default could be to install in system locations on Workstation and outside of system location in Silverblue. But actually, even in Workstation I think it might make sense to install outside of the system by default, of course upgrading existing packages that are installed in the base system should still work. The user could still make use of toolbox and rpm-ostree when that makes sense (layering system components such as drivers).
It seems atomic desktops are more difficult to approach because of this, as a new user myself reading the documentation, having to deal with toolbox and rpm-ostree is one of the first thing I was exposed to. Having a working dnf would make atomic desktops more attractive and approachable to users.
I see that dnf already has a --installroot=<path> option. Maybe I’ll try digging a bit more and see if it could be used on Silverblue. I’ll report here if I find anything interesting.
There is a plan to incorporate dnf into atomic desktops AFAIK, after switching from rpm-ostree to bootc.
In the meantime, as suggested above, you could try a Universal Blue image, e.g. Bluefin, which is based on Fedora Silverblue. Images are already delivered with bootc, come preinstalled with Homebrew, and it’s recommended to install apps either as Flatpaks or via brew, leaving the base image unchanged.
oh that’s great. I will try to find more information about that.
Thank you, I didn’t know about Bluefin. Might be an interesting glimpse at the future of Fedora, though if I understand correctly, this is a totally separate project and doesn’t necessarily represent what future Fedora will be.
No, it doesn’t necessarily represent the future of Fedora, but it’s a downstream project, and, as such, has many things in common.
They (Universal Blue) seem to be more cutting-edge than Fedora in certain areas, see for example bootc adoption[1]. On the other hand, I don’t think Fedora will ever propose Homebrew as a pre-delivered installation method.
I prefer to stick to Silverblue though (more tested and polished, upstream project, aarch64 images available for my Apple silicon Mac, etc).
You can obtain bootc images for Fedora Atomic desktops too, but it’s not yet the official method. ↩︎
Indeed, dnf would be what I would expect. I think telling people to use a package manager that installs out of the system base is a much more appealing communication than telling people to use toolbox and layered installs. toolbox and layered installs would still have a use case but it seems much more niche and for advanced use cases to me.
dnf and rpm don’t care where things are installed. The problem is that by convention, most RPMs write their contents to /usr. What you need is an ecosystem of RPMs built for a different prefix like /opt while still linking to the core system libraries in /usr. There are no serious technical hurdles to this; no one has taken the effort to build such an ecosystem because Linux distributions have traditionally been “bags of packages”, with no distinction between system software and third-party software, and adopted the convention that /usr is the package manager’s domain.
In the Atomic Fedora world, /usr plays the role of the /System directory on macOS or the C:\Windows directory on Windows. Homebrew works on macOS because the formulae are written to install everything in /opt/homebrew while linking to the system frameworks in /System. It would encounter the same problems as dnf on Fedora if the formulae dumped their contents into /System.
For future readers coming here: I tried using dnf on Silverblue by first installing it via rpm-ostree install dnf, then installing fish in /usr/local using dnf via dnf install fish --rootinstall=/usr/local --use-host-config but that did not work.
So it does seem that using a third-party package manager such as brew or pkgx is the safest bet for now.
Side note about this particular thing: you can let brew, stow, or similar package managers install things into /usr/local. It is a symlink to a directory in /var, similar to how /home is managed.
Right. I guess my interrogation was more: why doesn’t the built-in dnf do that by default on atomic desktops? The documentation recommends toolbox and layered installs but this really seems overkill for installing tools, which could perfectly well be installed outside of the system image (which just works with brew for example).
I’ve been trying to understand whether this is something that is planned for dnf. But I can’t quite get the information. It seems it is planned to include dnf but that running it on atomic desktops would tell the user to run rpm-ostree instead (or do the equivalent of what rpm-ostree is doing), I’m a bit confused here.
Atomic desktops do not have dnf installed.
Only the bootc containers have dnf but it is not capable of generating OSTree deployments, its simply for end-user modification similar to RHEL Image Mode.
Work is being done to replace rpm-ostree with dnf so that it becomes mostly seamless for end users but its not there yet.