LWN.net Logo

Is RPM Doomed? (DistroWatch)

DistroWatch takes a look at the RPM Package Manager. RPM was created by Red Hat, but it has been adopted by many other distributions, including Mandrake and SuSE. It has become a de facto standard, which might not be so bad except that various implementations are less than standardized. The article begins with a description of RPM "dependency hell", and goes on to look at other methods of package management such as Debian's .deb format and Slackware's .tgz format. Then there are source based distributions such as Gentoo and Sorcerer which have their own ways of dealing with packages.

DistroWatch has some solutions for the precieved problem:

  1. Learn to build your own RPMs.
  2. Petition the RPM distributions to adhere to common standards.
  3. Use more advanced package management tools, such as urpmi or apt-rpm.
  4. Switch to Debian or Slackware.
  5. Switch to a source-based Linux distributions, such as Gentoo or Sorcerer.
Is there a problem? If so what would you do to solve it?
(Log in to post comments)

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 2:06 UTC (Thu) by newren (guest, #5160) [Link]

From
http://www.distrowatch.com/dwres.php?resource=reviews
you can see that this article is almost 9 months old. I seem to remember a follow up article where the author said that apparently there were a lot of people that responded to his article and gave several reasons why they believed RPM was a good tool. I don't seem to be able to find it right now, though...

up2date anyone?

Posted Mar 6, 2003 2:37 UTC (Thu) by Kurrelgyre (guest, #5600) [Link]

The article overlooks the fact that few distributions use .deb for their package format and even fewer commercial applications ship as .debs. How difficult would working with RPMs be if only Red Hat produced them? How many 3rd party/community .deb packages are there out there?

It also highlights apt's use to solve the mentioned problems while completely overlooking up2date, Red Hat's own solution. Shawn Gordon's quote looks like it's all about where the packages are built--exactly how is that a problem for the end user? Hopefully his quote's out of date as well because Red Hat, as well as several other RPM-based distributions, is LSB compliant. And labelling the dropping of backwards compatability as a "trick" is a naïve viewpoint at best. One breaking version does not a conspiracy make and RPM dates back to the mid 1990s; should we expect those packages to work when the binaries within them probably wouldn't load on a current system?

How well do .debs fair during an upgrade of a system with manually compiled software stepping all over it's packages?

up2date anyone?

Posted Mar 6, 2003 4:51 UTC (Thu) by Strike (guest, #861) [Link]

Well, in the case of RedHat's LSB compliance ... RPM is the package standard simply because at the time it was the most popular packaging system. Aside from tarballs, you most often found RPMs of software. It was the de facto standard, so they "adopted" it as the actual standard. There's been a lot of (well-justified, IMO) grousing about this on a lot of the Debian lists. The whole package section of the LSB at one time (and may still) hazily referred to "Maximum RPM" as the specification for RPM instead of a simple online doc that could be included in the LSB itself. It seemed like they rushed through that section to say the least.

up2date anyone?

Posted Mar 6, 2003 16:00 UTC (Thu) by kingdon (subscriber, #4526) [Link]

LSB 1.3 has a new RPM section which replaces the previous reference to Maximum RPM (which as you probably noticed, wasn't really a complete spec; it would say "refer to such-and-such header in the RPM source" and things like that). So things are a lot cleaner now, and as far as I know, Debian is still compliant vis-a-vis packaging (using alien).

As for dependency hell, the LSB also addresses this, at least in the context of LSB applications. Namely, they depend only on a dependency called "lsb". If you look at the Debian "lsb" package (in stable, testing or unstable) you can see that this in turn depends on all the packages required to make a system LSB-compliant (with all their Debian-specific names).

Is RPM Doomed? (DistroWatch) Film at Eleven

Posted Mar 6, 2003 2:43 UTC (Thu) by smoogen (subscriber, #97) [Link]

I seem to remember this kind of story coming up every 6 months since I started working with Red Hat RPMS in 1995/6. Basically, RPM is doomed, it has all these problems, yadda yadda, and how it will be gone in 12-18 months. The posts/stories are almost the same as the Internet is doomed postings that used to be on USENET from 1989-1995 when I quit reading News.

Basically the dependency hell etc is a real matter. However, not having it has all kinds of other problems when you try to put some tar ball from a developer and you do not have exactly what they have... and you have no idea where to get them. Try dealing with .deb dependencies without a network connection and only some cdroms burnt a couple of weeks ago. They are pretty much the same problems... just forgotten about because of other tools (apt and a network connection) or they arent' as popular (random compiled tarballs.)

Is RPM Doomed? (DistroWatch) Film at Eleven

Posted Mar 6, 2003 4:59 UTC (Thu) by Strike (guest, #861) [Link]

The "apt without a network connection problem" doesn't ever seem to be an issue for me. After all, that is how the installer installs packages. It simply throws the CD info into the sources.list, updates the package lists, and goes from there. Granted, packages in isolation are not as easy a problem to solve since you can't be guaranteed what sort of system they will go on. And if you restrict it to a package environment that is and will remain relatively static (i.e. actual Debian releases instead of specifying the "testing" or "unstable" branches, which (ideally) constantly change), then you may have to settle with older software.

But, you must realize to people who really believe in the Debian Social Contract as a Good Thing(tm), these are really non-issues because ideally all the software on their systems will come from "main" and not "contrib" or "non-free" and certainly not some independent developer. To those who do believe in that way of thought, the question isn't "how do I design a standalone package that works across Debian systems", but rather "how do I package this and include it in the main distribution" since ideally you would be pushing open source software. Now before I go totally off on a tangent, I just wanted to summarize: the apt system that Debian uses was constructed with only Debian in mind, so the issues that exist with packaging software independently instead of part of a greater distribution weren't considered problematic.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 6:30 UTC (Thu) by ladislav (guest, #247) [Link]

I was wondering why all of a sudden there is so much RPM-related feedback in my mailbox -- until I found this link :-)

Yes, the article is kind of old. Yet, the issues remain and everybody seems to have an opinion about software management on Linux. When the article was first published, it was deemed slashworthy and I received around 500 emails about the story. I'd say that about 80% strongly agreed or mostly agreed with the sentiment expressed, the rest disagreed.

It's been a trend amongst the more serious RPM-based distributions to include some form of a apt-rpm system to manage packages (Conectiva, Yellow Dog, Vine, PLD...). I know of at least three distributions that moved from RPMs to DEBs (ESware, Voodoo, Gibraltar) while none moved from DEBs to RPMs. Also, if you look at all the new distros that have emerged recently, none of them are based on Red Hat (Gentoo, Xandros, Lindows, Knoppix, Yoper, CollegeLinux...), -- most of them choose either Debian or Slackware as a base.

RPMs won't go away, not for a while anyway. Red Hat is a big name and it stubbornly refuses any move to apt-rpm or similar -- that's despite the fact that most of its more advanced user base is clearly moving in that direction (judging by the amount of apt-rpm related traffic on their mailing lists).

RPMs are great if you have no desire to update software on your system (e.g on servers). But for desktop use, with all the great new software coming out all the time, they are a nightmare. There is no doubt in my mind that this is how most Linux users feel about RPMs.

Ladislav Bodnar
http://www.distrowatch.com

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 18:51 UTC (Thu) by dbreakey (guest, #1381) [Link]

While I would agree that RPMs do present problems, I have to disagree that it is not an appropriate choice for desktop user distributions; after all, I have been updating Mandrake-Linux, through their urpmi tool, reliably and consistantly for the last 12 months.

While this does mean that I am dependant on the Mandrake community (both commercial and user) for packaging of things that I am interested in, I have found that Mandrake packages are frequently available for even the most obscure packages, if I care to just search hard enough. And for those cases where packages are not available, I find that rpm -ta works well enough in the majority of cases (and most of the failures are due more to build dependancy naming conflicts, which are easy to fix by editing the spec file, than to actual build problems).

Personally, I think the only thing RPM really needs at this point is a consistent and predictable organizational and naming convention for packages (for instance, Mandrake consistently separates libraries into lib… packages which then become a dependancy of whatever package they were originally part of). Just my opinion.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 6:32 UTC (Thu) by djao (subscriber, #4263) [Link]

Couple of things ...
Similarly, there are many users who have moved from RPMs to DEBs, but very few who have chosen the opposite path.
In the past I would have tended to agree with this statement, but in recent months I know several people who for whatever reason have migrated from Debian to Redhat, and nobody from Redhat to Debian.
4.1 Build your own RPMs: This is not really a solution for the majority of Linux users.
The author may be strictly speaking correct (i.e., building rpms is not appropriate for over 50% of linux users), but the idea of building your own rpms is not the fringe solution that the author makes it out to be.

If you are given a source rpm, you use rpm -ba. For tarballs containing a spec file (e.g., GNU vcdimager), you use rpm -ta. For (stock) linux kernels 2.4 and up, there is the surprisingly little-known make rpm command. If all else fails, FreshRPMS has an excellent guide which is a lot less intimidating to read than the Maximum RPM book given in the article.

I have been building my own rpms for about five years. I administer a network of computers this way, and I couldn't be happier with the results.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 15:55 UTC (Thu) by yohan555 (guest, #4253) [Link]

I completely agree, I also administer a large number of machines and I simply rebuild RPM packages for my system. This often works out of the box and worst case scenario, I'll have to modify the Spec file a bit.

The only problem lately is that different distributions have started to use different rpm macros in their spec files, i.e. Mandrake to install Desktop shortcuts, so their spec files don't rebuild without modifications on a RedHat machine. So, the problem is less with RPMS than with the fact that there are diverging standards even within rpms.

RYO RPMS (was: Is RPM Doomed? (DistroWatch))

Posted Mar 6, 2003 18:32 UTC (Thu) by X-Nc (guest, #1661) [Link]

I have been using checkinstall for quite a while now and it's great when you need to install something that's only released in source form with no spec file. The latest version is quite capable of handling just about any aspect of the RPM phase and is quite simple to use. And, FWIW, you can use checkinstall to build .deb and .tgz files for Debian and Slackware based distros. Just wander over to freshmeat and check it out.

--
"Oops!" -- Me, one second after executing 'chown -R .*' on the main server.

Is RPM Doomed? (DistroWatch)

Posted Mar 7, 2003 4:50 UTC (Fri) by tjc (guest, #137) [Link]

I know several people who for whatever reason have migrated from Debian to Redhat, and nobody from Redhat to Debian.

Well, I did. :-)

Package management wasn't the primary reason for the move, but I discovered after the fact that it's quite a bit nicer to type "apt-get install" than to make a half dozen trips back and forth between a Red Hat mirror and rpmfind.net.

TedC

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 11:30 UTC (Thu) by dpash (guest, #1408) [Link]

Debian's strength is not .deb, dpkg or even apt, but policy and the fact that Debian packages
are designed to only work with Debian. Tools like lintian and linda make it very easy to make
sure that your debian package follows various aspects of policy and you only have one
distribution to target. You know it will work with a particular version of a dependancy, because
that dependancy is already in Debian. You don't get RPM Hell very often as your users will get
exactly the same package you used as a dependancy.

RPM based distributions will continue to have RPM Hell until they agree a package naming
scheme, agree file locations and program versions and have a large shared rpm archive.
Sounds a bit like United Linux really doesn't it.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 22:52 UTC (Thu) by ronaldcole (guest, #1462) [Link]

RPM's biggest flaw is that it's performance depends on the skill of the spec file writer. So blaming RPM for the faults/skills of the spec writer is a bit like throwing the baby out with the bath water. I've personally entered bugs in bugzilla for poor choices of package names (compat*-5 and compat*-6 are unable to coexist even though there is *no* package overlap) but Red Hat's response was best summed up as "feh". But that's not RPM's problem.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 12:06 UTC (Thu) by hensema (guest, #980) [Link]

Very badly written article. It blames RPM for various things it can't be blamed for:

- Upgrading an RPM-based distribution is risky at best
That's got nothing to do with the rpm format. A distribution can easily
be made such that it can be upgraded

- it has created enormous fragmentation between distributions
You can only avoid this using strict guidelines for packaging. Debian
does this. It's got nothing to do with rpm vs deb

The article goes on comparing installing a package using apt and a package using rpm. You can't install a package you've just downloaded using apt. And you can use apt on a rpm based system. This argument is moot.

Dependency hell. WHAT dependency hell? The dependency hell you get when you try to install a package built for another distribution?
Slackware has no dependencies at all. Or does it? On slackware the user has to solve the dependencies without aid of a packaging system. This is REAL hell.

I think the author is simply dislikes distributions which happen to be rpm-based. That's fine, but don't blame the rpm format for that.

Is RPM Doomed? (DistroWatch)

Posted Mar 7, 2003 19:27 UTC (Fri) by rmassa (guest, #2984) [Link]

Slackware has no dependencies at all. Or does it? On slackware the user has to solve the dependencies without aid of a packaging system. This is REAL hell.

I actually switched from redhat to slackware. Slackware (with checkinstall) is the easiest package management system that I've encountered. Its simple to upgrade packages and all of the necessary information is stored in flat text files to make for easy grepping and such. Of course, you have to be willing to compile your own packages.

apt-get for rpm is a great solution

Posted Mar 6, 2003 12:23 UTC (Thu) by ahornby (subscriber, #3366) [Link]

I've been using it for a while from freshrpms. Redhat should adopt support for that IMHO.

Solved by Gentoo

Posted Mar 6, 2003 13:20 UTC (Thu) by alspnost (subscriber, #2763) [Link]

Oh well, I took option 5 and switched to Gentoo. It's absolutely superb, and I could certainly never go back to clunky old Red Hat, nice though the latest versions look.

What's also little-known, of course, is that Gentoo's "portage" system can and does work just as nicely with binary packages, ie it would be perfectly possible to offer a "binary" version of Gentoo for those who didn't want to compile everything, yet who still wanted all the other advantages of a lovely software management system. But then that would miss half of the point of Gentoo - the optimisation.

Anyway, although "portage" is centralised and controlled by one organisation, which could be a disadvantage in proposing it as the new standard for Linux platforms, its elegance of design is a major breath of fresh air. I hope it continues to develop and improve, and maybe one day, the portage philosophy will rule for both source and binary distros....

Is LWN slashdot ?

Posted Mar 6, 2003 14:03 UTC (Thu) by bockman (guest, #3650) [Link]

Well, the answer is no, of course. But this item is so slashdottish in style and (lack of) original content that I could not help wonder if I selected by mistake the wrong bookmark.

IMO, this may be ok for the daily log, but from the weekly edition of LWN I would expect more content, some reasoned thought, more link to sites or articles showing the various opinion on the matter. This is what I think is worth paying for. One Slashdot is more than enough.

If you didn't had time to research a subject, fine: postpone the article. I would prefer less material, but more original one.

Is LWN slashdot ?

Posted Mar 6, 2003 16:35 UTC (Thu) by smoogen (subscriber, #97) [Link]

I find myself agreeing with this 100%. The topic wasnt really filled out enough for a weekly edition and not the quality etc that I expect from LWN.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 15:15 UTC (Thu) by erat (guest, #21) [Link]

RPM does lack some functionality. Good examples are selective installation of updates (currently, an update = a complete replacement, even if the fix is for one tiny chunk of the software) and the ability to "roll back" to a previous version without having to manually dink with configuration files, CD swapping, prayer, etc. But in my opinion, the major problems with RPM packaging rest squarely on the shoulders of the packagers themselves.

Dealing with init scripts seems to be a huge issue. There are RPM packages out there that don't put init scripts in their proper locations (for example, a symlink that connects /etc/init.d and /etc/rc.d/init.d in %pre goes a long way on systems that don't use correct init script directories *cough*OPENLINUX*cough*). Most with init scripts don't take into account any distros other than the distro on which the package was created. Almost NONE of them seem to take into account that chkconfig init script headers are only utilized on Red Hat and derivatives (hint: LSB headers and chkconfig headers can co-exist in the same file).

Distro companies aren't immune to packaging blunders either. Run a query on package "vendor" on any commercial distro (SuSE may be the exception) and count how many different ways these people spell, capitalize, and split up their own company names. Ditto for the "distribution" tags. Folks actually do use these strings, y'know... And one major software company who shall remain nameless has packaged the Linux version of its software in such a way that the packages try to take ownership of /etc, /usr/sbin, and /usr/man, just to name a few. Wow...

And I can't even begin to count the number of SRPMs that I've downloaded that don't utilize a "buildroot". The result of such an omission is that the software the SRPM builds is sledgehammered onto your running system and then packaged into binary RPMs. Imagine this happening with an important system library... If you rebuild an SRPM and all of a sudden your favorite X apps stop working, the SRPM you just rebuilt may be the culprit.

I know I sound bitter about this. I guess I am in a way, mostly because I've had to deal with spec file and init script entropy for so many years. The "fixes" are easy and require less technical knowledge than building a basic RPM package. Knowledge of the fixes and willingness to implement them seem to be the big issues. RPM technology provides packagers enough rope to hang themselves. The responsibility of avoiding being hanged rests with the packagers more than the packaging system.

(Having said that, I will add that I don't use RPM based Linux distros anymore unless it's necessary for work that I'm doing. I use MacOS X, Gentoo, and FreeBSD at home, and I have no plans on looking back.)

[OT] Systems used (was: Is RPM Doomed? (DistroWatch))

Posted Mar 6, 2003 18:54 UTC (Thu) by X-Nc (guest, #1661) [Link]

> (Having said that, I will add that I don't use RPM based Linux distros
> anymore unless it's necessary for work that I'm doing. I use MacOS X,
> Gentoo, and FreeBSD at home, and I have no plans on looking back.)

If only I hadn't had 5 computers get fried all at once a few months ago...

I've got an iMac running OS X (for which my 6 year old son is the whiz on, I have to ask him how to do anything on it). I have a laptop which is running RH 8 that I use as my main system (simply because I've been using RH for this since v2.1). I have an UltraSPARC 5 with Solaris 8 on it sitting under a chair in the living room (no place to plug it in). There are so many different Linux distros and other Software Libre (and commercial) OS's that I want to try it's not funny. I happen to still like BeOS, I want to get familiar with one of the *BSD's, Xandros is the killer Linux desktop distro at the moment (with Lycoris Desktop/LX just a hair behind), OEone's HomeBase Linux is the best "Internet Appliance" I've ever seen.

I wish I could try every OS, and flavour of, that's out there. Of the 30 or so I have tried I've found that there are some that are killer for specific situations.

If I wasn't so lazy I would build my own "X-NC Linux" distribution and then I'd have, with out question, the best OS in all the universe. ;-)

--
"Huh?!?" -- Me, two seconds after being told not to lean on that part of the wall and one second before the Haylon system activated.

RPM building underdocumented

Posted Mar 6, 2003 19:45 UTC (Thu) by ber (subscriber, #2142) [Link]

RedHat does not maintain a good and up-to-date documentation
for building rpms. For some parts building good rpms is a black art
best learned by example.

Better efforts to document and standardise rpm packaging practices
are a possible solution.

Is RPM Doomed? (DistroWatch)

Posted Mar 6, 2003 23:02 UTC (Thu) by mongre26 (guest, #4224) [Link]

I kinda get tired of the Debian, oh our system is so much better, we never have interdependency problems. You know why? Only debian uses debs.

It is a lot easier to solve interdependencies when one group makes all your packages.

Also debian is just one way of doing things, if it works well for you fine, but do not go around saying that your system will spell the end of another system when it should be obvious by now that it will not happen. If this was the case there would only be Mac desktops and Linux servers regardless of distro.

As far as Gentoo???? Please. For one system fine, but a nightmare if you manage dozens of boxes.

I cannot afford the time, or the power consumption to do all that extra work (compile, link build) for every node that should be done only once.

Perhaps a better question to ask about gentoo is not how much faster it is, but how much more electricity a default install consumes over a default binary install of another distro. Same goes for debian where it is simply time consuming to download and upgrade. I have a 52x CDROM and a calbe modem, I would prefer to use the faster of the two data transfers. Particularly if I have multiple systems to update/install.

Binary packages are simply more efficient across multiple nodes, and if I want I can still custom compile rpms for a particular architecture and then push them out to an entire cluster.

The most important thing about most Linux distros is not what package system they use but the fact they use one at all.

This IMO is one of the most important edges that Linux has over the competition. pkgadd on solaris and installers on windows/mac do not cut it. Efficient management of systems requires.

Ability to add packages, and this does not mean just add on packages, but core system packages. ie the entire system should be able to be removed/updated/installed one package at a time.
Ability to query a database of all install packages and they files
Ability to detect dependencies (or solve them via the package tool or third party tools)
Ability, and this is probably one of the most important features, remove the package and all of its associated files.

Whether the system uses .deb or .rpm is irrelevant as long as these core features are present.

As far as upgrading a system, which the author seems to feel is the reason why rpm is doom, this is a feature that simply is not something most distros care about, or in some cases is it compatibile with their business model.

Debian wants inline upgrades to be their primary model of distributing packages, so it is no suprise it works well, but the author makes the error of assuming that others actually consider that feature a plus. Personally I just want to download a CD, CD-R's are cheap and I can burn them at 48x now.

My $0.02


Is RPM Doomed? (DistroWatch)

Posted Mar 7, 2003 4:04 UTC (Fri) by bronson (subscriber, #4806) [Link]

You don't like Debian because you can't burn it to a CD?

Is RPM Doomed? (DistroWatch)

Posted Mar 8, 2003 3:26 UTC (Sat) by Peter (guest, #1127) [Link]

I kinda get tired of the Debian, oh our system is so much better, we never have interdependency problems. You know why? Only debian uses debs.

Not quite true (Debian has a few derivatives, and don't forget that almost all RPM-based systems were originally Red Hat derivatives) but we'll let that slide.

It is a lot easier to solve interdependencies when one group makes all your packages.

Certainly. I guess this one is a matter of perspective. You seem to be thinking "Dependency hell would still exist in Debian if people tried to install third-party packages." My point of view is "Why would I ever need any third-party packages?" Debian already ships over 10000 binary packages (granted, a lot less than that if you are counting source tarballs). Basically, if it's free software, it's most likely already in Debian.

Dependency hell could theoretically affect Debian, but the huge number of native packages that render it a moot point are a feature, not a bug.

The problem is not the pkg format but the infrastructure and tools

Posted Mar 14, 2003 12:55 UTC (Fri) by ringerc (subscriber, #3071) [Link]

RPM and DEB file formats really aren't that different. .deb looks so attractive not only because of Debian's strict packaging quality guidelines but also because there is USEABLE INFRASTRUCTURE (up-to-date regional and ISP mirrors) in place for easy updates, and the tools to exploit that. Debian mirrors are everywhere, and debian is designed to use them.

I can only speak for Red Hat at the moment, but when I noticed an RH mirror on my local ISP's FTP I thought "great, updates will be easy then". No such luck. "up2date" wanted to register my system with RH before doing anything, and then it turns out it only talks to RH servers. What's wrong with getting the actual packages from my ISP's perfectly good mirrors of redhat-8.0 and updates/8.0 ? Oh, thats right, no chance to push paid RHN. Up2date is a business tool for RH and not designed to be the best technical solution to the updates problem. Apparently its possible to kludge it to work with other servers, but I just ended up downloading the entire updates/8.0 directory off the FTP and doing an "rpm -F *" (plus pre-installing new dependencies etc) so that I could have all the updates within an hour not a week.

On a debian box I can install new packages and updates from a local mirror. That's important if you live in a country that thinks that data traffic costs money (Australia) and charges you for your downloads. *sigh*. If Progress Inc. supported Debian for their 4GL I'd be back in a second.

Perhaps distros like Mandrake are better about using local update resources, but RH is apalling like that. Sad to see given how nice most of the rest of it is.

Copyright © 2003, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds