I see discussion online sometimes that compares rpm-ostree versus dnf. I think this is wrong for several reasons. The first is that rpm-ostree actually links to libdnf - it has one foot in the same ecosystem. It’s helping to augment the RPM ecosystem too.
Second, I think discussing how software is installed on the host is only part of Silverblue. For people whose needs extend beyond basic GUI apps, I’d really like to see us emphasizing more having firing up toolbox and using dnf install inside there being one of the very first things people should do. It makes a lot of sense to use traditional package managers like dnf and apt in containers.
Yet another way to think of this is that rpm-ostree extends the ecosystem to cases like IoT where one really wants an image system that ensures identical builds across devices, etc.
For sure, the use cases of rpm-ostree and dnf overlap in some cases, but let’s keep things positive and consider how they complement too!
This is a perception that I have noticed floating around the discussions where there is some question of the path to take for a particular installation of a software package or group of packages. It seems, there is a misconception that layering is to be avoided at all costs, plus the general lack of comfort in container usage would seem to feed the idea that there is an opposing approach to package management WRT Silverblue. Personally, what attracted me to using Silverblue in the first place was largely the development path it promised to clean up. As such, the flexibility of layering was the first feature that fit my needs. The second thing that attracted me was the use of flatpaks for my applications I use day to day, such as various editors, etc… and the fact they updated independently of OS updates. Third, the promise of rootless containers, and using them for those specific cases where layering or flatpaks fall short.
Agree 100%. I have always viewed Silverblue as a orchestration of primarily three different methods of achieving the same computing goal. The solidity of an immutable OS with built-in flexibility that you can layer optional packages onto, can run rootless containers with, and the independence of flatpak’ed applications.
IMO I think it is more of a misconception on how to use this new thing that we have. Gentle coaching on the intent of rpm-ostree, ie. layering is acceptable, but try it out in the toolbox PET container first is an approach I have used that seems to work.