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?

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.

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.

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.

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.

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.