Even if dnf and zypper are 1000x faster than apt there, that alone wouldn't convince me to use them.
Packages have sticky-vendors, so you only get updates from the same vendor unless you choose to switch. Even if another the update is in a different package repository. This means you don't get flip-flopping package vendors when the same package is available from two vendors and they release updates one after each other.
Another example is the tooling around package/repository signing - Letting the user decide whom to trust without making them jump through hoops to manually import keys.
There's also a lot of things in the packaging itself designed to help support third party vendors. Dependencies tend to be configured with capabilities rather than package names. e.g. The kernel provides information about the binary api version which third party drivers can depend on. Third party kernel modules can also supplement/enhance (soft dependencies - inverse recommends/suggests) specific PCI ids so the solver will suggest installing them if available and compatible with your hardware.
In my view debian package management "just works" because the set of packages is carefully curated and tested, there's a high standard of package quality, and everything is available in one place. PPAs can present problems.
The rpm distro ecosystem philosophy is somewhat different. It's impractical to expect a single organisation to package all the software you will ever need, so let's provide tools to help software from multiple vendors to get along.
I would also say that dnf and zypper are better package managers than apt, in as much as they are faster and easier to automate. Compare the code here:
https://github.com/libguestfs/libguestfs/blob/1.29.43/custom...
Here is a relative simple package, done for both RPM and .deb. The RPM spec is 141 lines (excluding the changelog):
http://pkgs.fedoraproject.org/cgit/virt-top.git/tree/virt-to...
The .deb is actually shorter in this case, but split over several files, and uses cdbs which I find infuriating with its lack of documentation and multiple hidden implicit rules. If you have a Debian machine around, try reading the /usr/share/cdbs/1/ files some time. Remember also that for most Debian packages, the files come in a tarball or even a patch, which makes them hard to manipulate without obscure deb-* commands.
https://anonscm.debian.org/cgit/pkg-ocaml-maint/packages/vir...
Try upgrading from major versions and seeing what happens.
It's absolutely relevant
Given, I understand some people want "servers like pets" and Linux desktop to be a thing, in industrial applications it's usually not an issue.
In most cases, no-longer-specified items would be removed. BTW ansible sucks for this aspect (I use it extensively at a new place) ;)
My point is that, the modern attitude of "you can't trust what's on a server unless you build it from scratch or apply an image" is not the only valid way to do things, and is somewhat defeatist, like we're no better than windows where you can't guarantee that anything can be cleanly uninstalled / replaced. Is your package manager that bad?
Yum being dog-slow was very annoying. Updating all server lists for every yum command was very annoying. I customized various modules and scripts to use "makecache" and "-C" where appropriate, but that was an annoying task. And yum was still slower than I'm accustomed to a linux package manager being.
Finally having a couple of years experience with yum, I can confidently say that pacman (archlinux) and apt (debian) are worlds better. Maybe zypper and dnf make rpm not suck; I probably won't find out for a few years.
Today's "continuous deployment" world, that just "tear down and put the latest version" once a week is crazy.
A stable foundation is important, and updating it without breaking everything is needed sometimes.
It all depends on what kind of apps you are deploying and supporting. While I wasn't even discussing immutable systems in this capacity, some workflows work better for .com style applications. In a typical bank environment where you have thousands of legacy applications floating around, you are more apt to not be able to control the architecture and need to push out security updates.
In place updates here are fine, however, I still wouldn't want to do an in-place dist-upgrade across all of those systems, and then find out which ones of those thousand applications had problems. In this case, it's better to redeploy those applications if they need a new OS and the OS is no longer recieving security updates - and try to shift some of that burden onto those who maintain the application.
If you are just deploying a .com app though, you need a good backup/DR strategy, and it helps to be able to redeploy everything and take steps to not get attached to state on that machine.
This isn't the case. It updates information when the cache expires, so this will only happen about every 30 minutes or slow. It should also only take (usually) way less than a minute.
> BTW ansible sucks for this aspect
Yep, it's not meant to understand how to remove resources it doesn't know about. That being said, it feels like I've created PHP at times, and I don't mind people not liking it. Many of the ways we have to automate Linux systems (due to lack of structure and API) are kludgy at times, but removal of packages not present in a master manifest seems dangerous to me for various reasons (group installs, tools self-bootstrapping, work happening out of band). Fair enough.
> is not the only valid way to do things
This was not the argument for immutable systems (though I like them), but rather that you need a good disaster recovery strategy and this is likely the best way to handle a major distribution version upgrade.
Minor versions? Continue to do what you do. Major upgrades between EL versions are full of all sorts of fun.
I've typically seem them done with upgrade kickstarts and the like, and you don't get good error reporting there at all when things go wrong. There were some advances in pre-downloading and then doing upgrades but... yeah... not a fan of doing them in automated context.
> " I can confidently say "
Trying to drive it programatically, yum seems much better engineered to me than apt. One example recently (and maybe there's a way in apt to do this) was to be able to select just one repo to use during an update to grab packages from, and I was missing --disablerepo=* --enablerepo=X. But there are a lot of things like that. Config files also seem a lot more capable. My opinion there too of course.
It doesn't do full downloads of files, but (as of RHEL5) it still makes HEAD requests or something, re-processes package lists (I guess apt does this too), I dunno. "-C" makes a significant difference. I want it to take less than a second to make a decision or spit out information; other package managers can do that.
EDIT: also want to say, I appreciate ansible overall, and I appreciate your attitude towards it. I've been close to a project that was good for a couple of uses, got kinda popular, and then people wanted it to be good for all purposes...
When I do an apt-based dist-upgrade, the long part of the upgrade is not the single-or-low-double-digit seconds it takes to solve the deps, but the download and installation of the new packages.