Articles / Is it time to change RPM?

Is it time to change RPM?

New Linux distributions usually base their package management on one of two options -- Red Hat's or Debian's. Brazilian distributor Conectiva decided to go with RPM, but has reservations about its ability to provide smooth automated upgrades. In today's editorial, Conectiva's Claudio Matsuoka describes the problems he sees and what he thinks should be done.

The scenario

In the past few years, changes in the Linux world helped the operating system gain acceptance in the mainstream market. Package management has played no small role in this process. Thanks to dependency checking, the overall system consistency is kept. Thanks to file databases, removal of unneeded software is as easy as installing new, up-to-date precompiled binaries that are guaranteed to work on your system. Sysadmin skills are not a prerequisite to run Linux anymore; C and makefile knowledge are no longer required. RPM and Debian packages ruled the world, the first adopted by the vast majority of commercial Linux distributions. In a quick glance, the two systems are just two implementations of the same idea, with no major differences. A few details, however, make a big difference in the auto-updating process.

We first met automatic package retrieval and installation in the form of apt-get. Debian users are glad to have such a wonderful tool. One step ahead of package management, users can now keep all their packages up-to-date, and add/remove packages tied to an intricate dependency graph, by issuing a single command. And, even better, APT was designed to be system-agnostic, so no matter if you use .debs or .rpms; we'll all be happy.

Well, not quite. Mixing APT and RPM is an obvious step in making users of RPM-based distributions happier, and probably every vendor has considered implementing it. A few design problems, however, have made this goal not so easy to accomplish, and many distributions decided to use their own updating system. This is not a very good situation; it fragments the user (and potential developer) base, it may create incompatibilities, and it duplicates development effort. On the other hand, apt-get is ready, has proven to be reliable, and has a nice set of companion utilities such as apt-cache, apt-move, apt-zip, and gnome-apt.

The problem

Just like a painter who paints the floor of a room and gets trapped in a corner, certain features in RPM seem to have been designed to make integration with APT impossible (which makes a lot of sense if you consider that RPM is older than APT). File dependencies, for instance, make your reverse dependency database grow to insane proportions, and the existence of packages optimized for different processors on the same architecture doesn't help. But that's not the problem. Thanks to the efforts of Alfredo Kojima of WindowMaker fame, now working at RPM-based distributor Conectiva [Ed: Conectiva is also Mr. Matsuoka's employer], most technical issues have been quickly addressed and, despite claims that it couldn't be done, it actually works. So is updating RPMs now as simple as updating Debian packages?

Yes and no. Yes, you can install, remove, and update packages in a painless process with all dependencies resolved. No, it's not the same thing. RPM packages can't be configured interactively. They won't ask you if you want to keep the current version of a configuration file, install a new version, or compare the two versions. They won't stop services before updating and restart them afterwards. The MTA won't ask you a few questions and configure itself. They won't even issue a warning to the administrator. We need to walk one more step to have it work properly.

The solution

First of all, it would be a valuable addition to RPM to provide some mechanism to configure all unpacked but unconfigured packages. Pre- and post-install scripts, as well as pre- and post-removal scripts, should be executed appropriately to allow smooth upgrading of running services. Package maintainers would have to add such scripts to their packages and make sure they'll not break the system the package is being installed on, keeping in mind the diversity of RPM-based distributions out there. Auditing, predependencies, package flags, and auto-deconfiguration functionality must be implemented. Small details like "obsoletes" with version numbers should also be provided, and package priorities -- at least "essential" marked packages -- are a nice thing to have.

Most of the effort required by such a change would be in the packaging policy. A few issues still remain unsolved, most notably how to handle multiple versions of the same package installed on the system and what to do with packages with the same name but different vendors.

The future

Indeed, the above description matches the current features of Debian packages. But all these features, regardless of what packaging system they come from, are important to making auto-updating easy, reliable, and not likely to stop your system due to misconfiguration, removal of an essential component, or even security holes introduced by mismatched configuration files. "So what's the point," you may ask, "of implementing something that's already there, just under a different name?" A few issues must be considered:

  • RPM has a huge install base and is widely supported by many vendors and developers. Switching is not cost-effective. RPM is one of the major standards (the other being .deb), and you can't simply drop it.
  • RPM has a big acceptance among users and developers. Forcing them to change is not possible or desirable.
  • The changes required to have a smoother integration with apt-get are mostly in the packaging policy; the changes needed in the tool itself are not great.
  • Buildmasters and packaging people like file dependencies and consider them a Good Thing(tm).
  • RPM has features not available in .deb, such as the ability to keep different versions of the same package installed as long as they don't overlap in the filesystem.
  • RPM may be adopted as an LSB standard.

Is it time to change RPM to allow smoother auto-updating? Will it be the start of a road for .rpm and .deb interoperability, or will it lead us in the opposite direction, restricting the installation of software packages to the ones specifically designed for your RPM-based distribution? Should the LSB be concerned about these issues? What role will be played by auto-rpm, up2date, and other auto-updating tools? Or shall we leave things as they are, and declare that full apt-get functionality is an unneeded feature?

Claudio Matsuoka (
is striving to finish his dissertation on robot dynamics simulation and receive his M.Sc. degree in Industrial Computer Science.
Claudio Matsuoka (
maintains a few free software packages, including the xmp mod player.
Claudio Matsuoka (
works at Linux distributor Conectiva doing miscellaneous hacks, including work on the V4L, Colour Quickcam, and OV511 kernel drivers. He keeps a diary at Advogato.

T-Shirts and Fame!

We're eager to find people interested in writing editorials on software-related topics. We're flexible on length, style, and topic, so long as you know what you're talking about and back up your opinions with facts. Anyone who writes an editorial gets a freshmeat t-shirt from ThinkGeek in addition to 15 minutes of fame. If you think you'd like to try your hand at it, let know what you'd like to write about.

Recent comments

18 Mar 2001 03:52 Avatar eduardolinux

Re: apt-get is a solution... but not for experienced users
Choose version: English (#english)

Escolha versão: Português (#portug)

You guys should know that Debian has the very best (un)installing system of all of them. All of us know that rpm is defective, and try to make it |compatible| with deb may sound like a utopic dream. Well, dreams are the main fuel of several things, but i still guess that a dual database system is the best option...

Honestly, I don't know... deb is very good to rpm, but I hope Claudio can do a very well job.

Todos vocês devem saber que o Debian tem o melhor sistema de (des)instalação de todas as distros. Todos nós sabemos que o rpm é defeituoso, e tentar torná-lo |compatível| com o deb pode parecer um sonho utópico. Bem, sonhos são o combustível principal de várias coisas, mas ainda acho que uma base de dados dupla é a melhor solução.

Sinceramente, eu não sei... O deb é muito bom pro rpm, mas espero que o Cláudio possa fazer um bom trabalho.

29 Oct 2000 06:34 Avatar fredlwm

apt-get is a solution... but not for experienced users
You can make the best advanced InstallShield(tm), but I'm one of those that'd never trust binaries from third parties, aside those shipped with my distribution. What I see is that apt-get (at least the one shipped with Debian) is doing basically what the Windows users always wanted, facility without security in mind. I don't agree that "it is well known that building from source is no better than installing pre-built binaries unless you carefully audit every piece of code you compile". I'm still someone that likes to do the job. I've heard a lot of complaints from people using apt-get, especially when they upgraded packages and things stopped working (should I mention upgrading libraries?). But apt-get accepted to install such applications. I played with RedHat for 2 years and never enjoyed their package manager. I never played with Debian because I don't like their package manager and ideals, despite it being "GNU/Linux". I wanted simplicity, and I found Slackware. If you're an experienced user and want
a package manager, then use what fits your needs, but make your own packages.

28 Oct 2000 16:44 Avatar cmatsuoka

Current RPM+apt status
This is what it already does:

[root@pokey:/root] apt-get update
Hit http://zaphod.distro.conectiva latest/conectiva/base/pkglist.001
Ign http://zaphod.distro.conectiva latest/conectiva release
Get:1 ftp://mapi2.distro.conectiva 5.9/conectiva/base/pkglist.001 [186kB]
Get:2 ftp://mapi2.distro.conectiva 5.9/conectiva release
Ign ftp://mapi2.distro.conectiva 5.9/conectiva release
Get:3 ftp://mapi2.distro.conectiva 5.9/conectiva/base/pkglist.002 [86.7kB]
Fetched 273kB in 4s (58.3kB/s)
Processing File Dependencies... Done
Reading Package Lists... Done
Building Dependency Tree... Done

[root@pokey:/root] apt-get install pingus
Processing File Dependencies... Done
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
ClanLib Hermes
The following NEW packages will be installed:
ClanLib Hermes pingus
0 packages upgraded, 3 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/1561kB of archives. After unpacking 6198kB will be used.
Do you want to continue? [Y/n]
Executing RPM (-Uvh)...
Preparing... ########################################### [100%]
1:pingus ########################################### [ 33%]
2:ClanLib ########################################### [ 66%]
3:Hermes ########################################### [100%]

[root@pokey:/root] apt-get remove Hermes
Processing File Dependencies... Done
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be REMOVED:
ClanLib Hermes pingus
0 packages upgraded, 0 newly installed, 3 to remove and 0 not upgraded.
Need to get 0B of archives. After unpacking 6198kB will be freed.
Do you want to continue? [Y/n]
Executing RPM (-e)...
cannot remove /usr/share/games/pingus - directory not empty

"Automatic installation" and "automatic handling of dependencies" are implemented, but "interactive config when needed" isn't (we have debconf integration planned to handle package configuration). Note, however, that deferred configuration will depend on database format changes or an extra database to keep the package status, and a strong packaging policy is needed to keep packages consistent with each other.

Also we need a better (faster, smarter, more reliable) dependency check, either to see the which packages must go in the same transaction when installing with rpm -Uvh, or to allow apt itself to reliably resolve all the stuff (currently it asks rpmlib, and it returns some faulty answers :/ -- bad rpmlib!) and install using --force --nodeps. Otherwise, all packages being installed must go in a single transaction, hugely slowing down the process if a large number ( > 300) of packages is going to be installed.

28 Oct 2000 13:21 Avatar scottgnet

RPM vis-a-vis APT-GET

I've been running RedHat at work and at home for more than two years (though I have 12 years of Unix sysadmin experience in all flavors, including UNICOS...).

The most important requirements for me for any packaging system:

Automatic installation
Interactive config when needed
Automatic handling of dependencies

I just switched over to Debian at home, and what a dream apt-get is! I will probably never go back to RedHat or any other RPM-based OS. I'll be switching over the systems at work in a couple of weeks.

My suggestions:

Merge RPM and Debian
All vendors adhere to File System Standard


23 Sep 2000 14:09 Avatar cmatsuoka

New features in APT
Regarding some features requested by a Slashdot reader and listed in a previous comment: the "version pinning" feature is already in the apt CVS repository, as published in Debian Weekly News ( Also Jason Gunthorpe has a proposal ( for package urgency:

Now that APT has a pinning mechanism it would be very nice if you could automatically install higher urgency upgrades and leave low priority stuff behind. ( ... ) The idea we struck on was for each package to have a 'urgency serial number' which exists on the ring [0...N]. The difference in the priority serial numbers of any two packages indicates how urgent the upgrade is.

About Antonio Marcelo's comment above, it is well known that building from source is no better than installing pre-built binaries unless you carefully audit every piece of code you compile, and few users consider auditing code a real pleasure.


Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.


Project Spotlight


An efficient tagger for MP3, Ogg/Vorbis, and FLAC files.