I'm not sure what the OP 'mergy' intended, but I'd guess that the intended reason had to do with better ecosystem curation. Under the hood, my understanding is that .rpm is marginally inferior to .dpkg, but not remarkably so. E.g. using cpio instead of gz as the format basis. So by elimination, the only reason to prefer .rpm would be the rpms, if you follow.
As a longtime Fedora user and a recent emigre (post-Snowden) to OpenSuSE, I agree that there is much to love about the selection of RPMs available, especially under Fedora. Although I'm sticking with suse for the lightning-fast zypper (still noticably faster than yum or even its slated nextgen replacement dnf!) and well-thought-out snapper utilities. But that is OT.
Mostly it's a matter of picking your poison. dpkg allows some things that RPM doesn't, and vice-versa. dpkg does have some nice features (well, features I can't remember, except for I went "Ooo, I want rpm to have that" when I saw it)
One thing that dpkg has that really annoys the hell out of me is allowing for user input during the transaction. It makes unattended upgrades impossible
In general Debian/Ubuntu packages do not prompt the user with debconf questions these days, although there are occasional leftovers in old packages if you upgrade via a terminal with apt-get update.
You can define an environment variable, DEBIAN_FRONTEND=noninteractive, to force even the worst-behaved packages to never ask a question.
You can set those configurations, certainly, but it's up to the package maintainer to actually respect them. At my previous company, I occasionally ran into packages that insisted on trying to read from the terminal, even when installed noninteractively, with all configuration flags set to noninteractive. I can understand the potential appeal for a lone individual working with a small number of hand-maintained systems, but when working with a large cluster, interaction during package operations is just a horrible misfeature.
Just to provide a similarly brief and pointless argument: I strongly prefer yum/RPM to apt-get/deb, both as a package maintainer (for tens of thousands of users) and as a system maintainer with dozens of servers to maintain.
Both yum and apt-get have excellent dependency resolution. I don't really know what else to say about it. I can remember the days of "RPM hell" (though I rarely found it all that problematic) as I've been using Linux as my primary server and desktop OS since 1995, but yum was in widespread use by 2005. It's been a long time since missing dependencies was a thing you needed to think about on any modern Linux distribution.
My preference stems from the following:
1. yum repos are so simple to create and maintain! One command, one directory, no files except the packages themselves. Contrast this with apt-get...it literally took me weeks to figure out how to create an apt-get repo. It requires several configuration files, which are generally human maintained (as far as I can tell, the docs for maintaining a repo separate from the Debian repo are awful and leave more than half of the process out completely, to be guessed and googled...they assume you only want to add a package to the Debian repo, not create a new one). It is also inefficient as hell. Generating our Debian/Ubuntu repo meta-data takes an order of magnitude longer than the yum repos.
2. Packaging RPM is much nicer, IMHO. If you don't need patches, it's just one file, the package-name.spec, plus the tarball. If it's a standard "./configure; make; make install" process, your spec file can be almost empty. The spec file is well-documented (Epoch is tricky, and a couple of the macros aren't immediately obvious, but in general, I can answer my questions by reading the docs). Debian requires several directories full of files for every package, and the documentation is obtuse. Again, it took me a long time to figure out how to package for Debian, and there's no good source for what tools you use to create and maintain packages. Wanna sign those packages or repos? Good luck! There are three or four different ways documented, and it was not at all clear which was the right way. I had to dig into the Debian repos to see how they did it, and try to replicate it. I think I'm doing it right.
3. As a user, I dislike apt-gets tendency to want to remove packages based on dependencies no longer existing...so, if Apache were installed to satisfy a dependency in another package, and you remove that other package, apt-get will (with some configurations, seemingly the default) ask if you want to remove Apache. Even if you have a hundred VirtualHosts configured and rely on Apache for everything! I find some of apt-gets other defaults alarming.
4. yum has mock. mock is amazing. Building packages for any RPM/yum-based distro with one command and one configuration file (and maybe a custom repo, if there isn't already one) is so awesome. As a package maintainer, this would be enough to win my heart forever. apt-get has some kind of fake root thing, or something, but I can't figure it out, so I have to maintain a VM for every Debian/Ubuntu version we support. This sucks and is tedious as hell.
But, if I had to live with apt-get, I certainly could. They are, honestly, both amazingly great technology, and I can't imagine life without a good package manager. I hate Windows and Mac for this very reason. I can't believe people think Mac OS X is acceptable, given the awfulness of package management on the platform. Even Windows has better package management than Mac OS X.
Some amazing things about both:
yum has groupinstall and apt-get has tasks. Super cool! Install a huge swath of packages, for achieving a specific goal (like "Development Tools" or "Gnome Desktop") with one command. Brilliant.
Easily install all the dependencies you need to build a source package, based on it's specified build dependencies. How amazing is that? Not only can you install the source code and the config files, patches, and data files you need to replicate the package from source, you can also replicate the needed build environment easily. (Add mock on yum-based systems, and you have packager heaven.)
You don't need those virtual machines if you use pbuilder. All builds will run under the same kernel but if it's affected by that you're doing weird things. Also, your package shouldn't depend on any meta package as it's bad style (what if that package drops a dependency you relied on?). A good package lists only the bare minimum dependencies needed to get it to work (but under Debian may recommend and suggest other packages to go along with it).
I read about pbuilder, but couldn't figure out how to make it work. Again, the documentation for the apt-get/deb ecosystem is awful. If I thought I knew how any of it worked, I'd write new docs...but, our Debian/Ubuntu repos are awful (they work fine for end users, but they are awful to maintain...I must be doing it wrong because it's so slow to regenerate and requires so much human involvement, but I don't know how to do it right). And, not only are the docs difficult or non-existent, the tools aren't very discoverable. Once I knew mock existed, I was able to get it up and running mostly by playing with it and looking at examples. I wasn't able to figure that out with pbuilder.
A quick googling just now revealed the Ubuntu wiki has what looks like good documentation for pbuilder, so I may be able to make it work now. It doesn't actually look that difficult (though it seems to require pretty advanced shell scripting for some things that seem like they ought to be in there with a command line switch or a config file option, but my reading of it was cursory and it may just be a weird bit of showing off in the docs, and shell scripting isn't actually a necessary part of the process). But, with truly awful docs, as they existed when I was trying to use it several years ago, I couldn't make it go.
I really don't hate apt-get as much as all of this makes it sound like I do. As a user, apt-get it fine. As a maintainer, I find it extremely frustrating. If the docs were better, I'd probably like it more (though not as much as RPM/yum...the simplicity of maintaining packages for a yum repo is really hard to beat).
My impression is that they got a bad rep long ago before there were decent package managers. As I recall, you had to install dependencies manually and updating a system could get nightmarish. Nothing really wrong with rpm as a package technology per-se, but before yum it was a lot less friendly.
Just a couple of days ago I was doing an upgrade from 6.4 to 6.5 and yum died in the middle; fixing that was quite hellish as rpm somehow decided that multiple conflicting versions of several packages were installed at once (eg glibc v131 and v137), and it wouldn't do anything until that was fixed (it wouldn't even attempt to fix the problem until it was fixed... "yum-complete-transaction" just complained about things being inconsistent and wouldn't roll back or forwards - "transaction" my arse). Ended up fiddling with "rpm --no-deps" to fix individual packages after drawing out the dependency graph by hand :(
I've had problems with individual .deb packages before, but never broke the whole package management system quite like that before :P
That’s not something that can be made reliable with either rpm or apt. The only options for reliable upgrades are 1) nix model or 2) filesystem transactions/snapshots. Especially, yum has official plugin for making LVM/Btrfs/ZFS(?) snapshot before committing each transaction. I imagine there’s something similar for Debian/Ubuntu.
I did that, it bailed out because it wanted dependency problems to be fixed first (and the dependency fixer bailed out because it wanted the dupe problems to be fixed first)
Indeed, but even with YUM, the process is unsavory and the number of sources is surprising limited. I ended-up just compiling from source because it was faster than trying to deal with RPM dependency problems.
What you mean number of sources is limited? The distros come with their own repos with a large selection of software.
When you go outside of that, you need to have a specific reason...like going to RPM Fusion to grab things like non-free codecs.
I'm just guessing, but it sounds like you're going to rpmforge and downloading a random RPM, maybe it's not even for your distro, and installing it and then trying to find all the other dependencies and in the end you've got Fedora, CentOS, and SuSE packages all forced installed on the machine and maybe whatever you were trying to do worked. That tends to be what people who bitch about yum/rpm are doing: they're doing stupid things.
RPM/Yum works just fine for 99+% of its millions of users.
For me in past years on Red Hat, Fedora and SuSE the RPM repos have a way of corrupting themselves almost irreparably. On Ubuntu (Debian based) if things go wrong I've always been able to run a few commands and get things nice and stable again.