I dunno what people mean when they talk about RPM hell
When people talk about RPM dependency hell, I really have no idea what they’re talking about. Here’s a factual look into RPM that should set the record straight:
Warning ahead: please note that I’m not gonna discuss Debian vs. Red Hat, but dpkg vs. RPM.
RPM, combined with a good package manager such as Smart, is vastly superior to the competition:
The strengths of RPM
- No indirections — 100% of the times, the manifest corresponds to the installed files. Have you seen dpkg detours/indirections (dunno their name in English)?
- Built-in integrity checking.
rpm -V. Can’t get any easier than that. - The dependency system is cleaner. It allows and actually by default generates dependencies on files, which rocks when several packages provide the same functionality.
- The RPM philosophy doesn’t allow interruptions during package installation or removal. No stupid questions about config files getting replaced or not, license agreements and configuration questions. This guarantees unattended transactional installations/upgrades (dpkg does not guarantee it without extra effort, because it defaults to interactive behavior) whereas with dpkg, if you answer one question wrong, your system may stay unconfigured. I know it because I lived it. I’d very much rather have the package come in a default useful configuration then configure it than have an assistant interrupt me upon installation to ask me how I want to configure it.
- RPM supports two versions of a package with the same name, whereas dpkg does not. I know this because I have a machine with
kdelibs3.5.7 andkdelibs1.4 to support Katalog from KDE 1.0, and no broken dependencies. However, this is regrettably a theoretical advantage because as of late many RPM-based distros have picked up the bad habit of naming stuff after Debian package conventions (think libXXX2.2); the Debian practice is both unneeded in the RPM world and stupid because the version of the package does not conceptually belong in the package name, and doing that constitutes a hacky workaround around inferior technology which RPM does not need.
The disadvantages
The only things RPM has going against it? It’s a bit harder to prepare spec files for RPMs, and it’s hard to prepare distro-agnostic RPMs, which has the logical consequence of reducing availability of RPMs ready to install. RPM-based distros should take a clue from deb-based ones right now, or else they risk continuing to get kicked in the ass for the foreseeable future.
Discuss.
November 14th, 2007 at 5:21
dude, you are insane. in mission critical systems, you CANT HAVE “the package come in a default useful configuration then configure it”. thats just stupid. too bad dpkg trashed your system, but it isnt designed to protect against ebkacs. and for your last point, why the hell would you need two packages with the same name? is much more useful to learn the version from the name, besides having to type apt-get remove foo -where-version=xy would be a pain in the ass. my experience with rpm-based distros was always one of rpm-hell. dpkg may be “inferior” (have you ever designed a package management system from scratch? yeah, i thought so), but i cant remember ever having a single problem related to conflicting debs, unavailable library versions, having to –force like mad, etc. etc.
November 14th, 2007 at 6:03
Carlos, you are wrong. Let me teach you a thing or two.
On mission-critical systems, when installing new packages, you use proven configuration taken from the test staging system, overwriting whatever configuration came with the package. You do not wing it, answering questions that haven’t been answered before, because you need repeatable behavior, and syncing config files is much more repeatable and automatable than answering questions multiple times.
In upgrade scenarios on mission-critical systems, you do not want your configuration to change across minor upgrades. That’s why the prompt for config overwrite question is wrong and unnecessary in dpkg. I do, however, value the fact that dpkg offers you to diff the new and current config — but I would like that prompt to just disappear either while upgrading packages and postpone the decision until after the transaction completes, or give me the option to review config changes before the transaction even begins.
dpkg didn’t trash my system, but it left over twenty packages unconfigured over a blocking question prompted by dpkg that kept failing. fixing the issue took major hackery.
It is absurd and dangerous to perform configuration on installation, because installation/upgrade should be transactional, and if the inst/upg fails, you are left with a half-completed transaction.
And for my last point (the stupidity of putting the version number in the name of the package — where it doesn’t belong), did you even read the arguments I raised against it? I suspect not. Please reread because I’m too lazy to answer your question twice; hopefully this time you will parse the sentences and read the two perfectly logical and justified reasons I gave.
Honestly, I don’t know why you experienced RPM hell. But I’m willing to bet one of my computers that you very likely did rpm -ivh –force at some point. Which you just proved.
And all this, my friend, is what you are wrong.
Plus I hate when people don’t read logical arguments, simply answering with their own gibberish and biased views.
November 14th, 2007 at 7:18
Ya Carlos, I hate you.
November 14th, 2007 at 8:09
The more I use Linux, the more I hate its file system. rpm is an accessory before, during and after the fact to that mess. If rpm could allow me to use install two versions of an application (say KOffice 1.6 and KOffice 2.0) together, I’d tip my hat to it.
November 14th, 2007 at 9:27
Oh, but RPM DOES allow you to install two versions of the same program. However, for that to work, the RPM needs to be built to install the files to different paths, which is not a difficult undertaking.
Please complain to the packagers of the KOffice program instead of to the RPM developers. In fact, just do a rpm -qi koffice at the terminal to figure out the e-mail addresses of the guys you should bitch to.
November 14th, 2007 at 10:20
ahahahaha, i dont know what the hell you thought i was referring to with “mission critical system”, but it wasnt your desktop machine. the whole point of mission critical systems is that THERE ARE NO MINOR UPGRADES. you only upgrade if you absolutely have to, in most cases because the critical software you are running was updated and you positively absolutely need the new functionality. that means testbedding like hell, a process you cant seriously automate but for the most trivial of applications. so yeah, i very much appreciate the fact that dkpg gives me 100% control of what happens in /etc, so i dont need to spend another 5min grepping what went wrong every time some package decided to change its config syntax.
upgrades are transactional only in your desktop machine or mom&pops shop web servers. the big boys however need 100% control of what changes are being made by the upgrade process.
and if you cant see the that the version number BELONGS in the package name, well, good luck managing more than one software version on a single distribution on just one machine. maybe its just me (and most distribution packagers around the world), but i like being able to instantly know what package versions are installed just by listing their names.
November 14th, 2007 at 10:57
Carlos:
I guess you forgot your cerebrum today.
A minor (but required, concepts orthogonal and not mutually exclusive) upgrade in a mission-critical system would constitute, for example, a security upgrade of a package to a new micro version. Happy with the definition? Does it fit your convoluted strawman?
What is it about grepping that you mention? First, config file syntax NEVER changes across security upgrades (by definition, micro version ones, see above). Second, RPM NEVER alters your config files if they have been modified — it creates .rpmnew files alongside them, exactly to prevent what you’re implying RPM does — destruction of the system. Clearly you know but a nugget of RPM and yet you think you know it all.
Taking these two considerations into account, and there’s no reason to untransactionalize upgrades under any circumstance, especially if they’ve been “testbedded”. You inventing a word for the meaning of the verb “to test” doesn’t make you one iota right. And I remind you that it was ME who brought the concept of testing/staging to the conversation, not you.
Hey, if you need your configuration to be exactly as you required, you probably have a configuration engine deployed, or you build your own RPMs with included configuration appropriate to redeploy your service as fast and repeatably as possible, in case of total catastrophe.
And if you cannot see that your wrongheaded opinion is wrong — and that’s what it is, no more than an opinion backed on no facts and a blatant misunderstanding of the elementary meaning of the words “name” and “version” — I suggest you open your Merriam-Webster dictionary on the N and V sections, then read a couple of books on database normalization. Maybe, just maybe, you’ll learn enough to understand best practice and excellence in software development and system administration. Tip: what you’re advocating for (cobbling two types of unrelated shit of different data types and natures) is called data denormalization in the professional literature, and unless there’s an inescapable technical need (dpkg’s shortcoming is a good example) you should never do it. Perhaps you could start a new movement to advocate inclusion of package byte size in the name? Hey, it’s always useful to “list your packages and see which one is the largest, isn’t it”?
And don’t be a liar. rpm -qa will show you the package name and the package version, so don’t try to fuck around with my readership spreading blatant lies about “how you like to see package versions when you list them packages on your system” and then implying that RPM doesn’t do it. Type rpm -qa then go “Ooooooh…. how did I ever miss that? Perhaps it was in the manpage?”
You’re just running around circles changing the question when you see your arguments vanish poof into thin air by mine. And you’re just an armchair theorist who can’t even spell dpkg, and doesn’t really know much outside his two-feet deep pond.
Ignorant punk; go learn your tech before you continue to get grilled here.
November 14th, 2007 at 12:24
this is awesome “A minor (but required, concepts orthogonal and not mutually exclusive) upgrade in a mission-critical system would constitute, for example, a security upgrade of a package to a new micro version. Happy with the definition? Does it fit your convoluted strawman?” do you really think minimal security upgrades are viable (or even necessary) on 100+ node clusters used 24h by people around the world? have you ever worked on a project bigger than setting up someones mail and webserver? ahahahahahaha i guess not.
November 14th, 2007 at 12:29
Carlos:
If you’re running a 100-node cluster for specialized computing applications, why are you even discussing your favorite nitpicks about RPM, and on top of it acting like an expert? Aren’t you an expert on customized environments instead?
This is a packaging systems discussion, and if you’re an expert on MOSIX or straightforward SSH 100-node clusters, your qualifications do not precede you, because knowledge on that domain does not necessarily transfer to systems and network services management. And your ignorance of basic aspects of RPM, gleaning through your comments, certainly show your lack of knowledge.
How very philistine of you, don’t you think?
And by the way, I don’t manage a cluster. I just manage 45 machines… which run 12 VMs each.
November 14th, 2007 at 12:31
Good points to know and think about. But I feel apt-get seems to work much faster than rpm installs. I am not a package builder. But in my experience, I used SuSE and Mandriva, installing packages using urpmi and yast are frustrating because it takes much time to load and install packages. I picked the fast mirrors near my country yet rpm seems a bit slow. Apt-get install is blazingly fast. RPM distros should concentrate on this respect.
November 14th, 2007 at 12:46
Sid:
You’re right. It takes more time to install N RPM packages than N deb packages (when you compare RPM to dpkg, its functional equivalent). This has a simple explanation: RPM tracks file dependencies, which (if you list the average dependency list on RPMs) roughly doubles or triples the amount of dependencies RPM needs to satisfy. Combine it to the fact that rpmbuild tends to be rather exhaustive when it auto-detects dependencies, and you get the slowdown.
On one hand, you get slower performance — and the performance hit is substantial because dependency resolution time is proportional to the multiplication of the dependencies involved in the transaction set plus the dependencies registered in the package manager database.
On the other hand, the probability that you’ll install a library upgrade that breaks your existing system goes down, because your program will be requesting a particular library as part of the file dependency pull. That’s just one example of the increased system integrity RPM gives you over dpkg.
But RPM installs are still pretty fast. The problem is that you’re comparing urpmi, yum and YaST against apt-get, which add to the dependency resolution length. Apt-get is brutally fast because it has far fewer dependencies to consider, and because it’s good software. YaST, urpmi and yum, in comparison, not only have to deal with more dependencies to match, but they themselves are dogs.
Use Smart. Smart is rather slow to start up (two to three seconds) because it loads and regenerates a cache. But once it’s processing, it’s fast enough for anyone’s needs. It also has a GUI, very similar to Synaptic, but more powerful in that it directly allows you to pin a particular package to either a version or a repository source. It also never touches the network unless explicitly told (my major grip with yum). And the dependency resolution is superior to anything… anything! I’ve used urpmi, rug, yum and apt-get… and nothing ever has compared to Smart in its ability to do the right thing.
Which is exactly what we want — a package manager that does the right thing.
Oh, Smart is perfectly capable of not only fixing broken RPM systems as well (Carlos, heads up, interesting tip for the next time you go against common sense and –force a package) but it can also perform regular package management on systems with broken dependencies (try that, apt-get!) and (get this, Carlos!) it handles (correctly built) packages of different versions with the same name! How cool is that?
February 17th, 2008 at 18:03
Though this isn’t to say that RPM is perfect. For example, I’d love to see it work across platforms. You get a Debian .deb on Ubuntu, and it works. I’ve heard not always the same on RPM based platforms (have yet to confirm this as I just installed SuSE).