In a followup to Claudio Matsuoka's "Is it Time to Change RPM?",
Alfredo Kojima offers news of Conectiva's APT/RPM integration work,
gives the reasons he thinks it's superior to other RPM frontends, and
hopes it will provide a means for bringing the various Linux
distributions closer together.
Dependency management is an important feature of package management
systems. It helps keep system consistency, making sure that
everything needed for a certain piece of software to work is there, in
the expected version.
But tools such as rpm or dpkg have limited handling of dependencies.
They're limited to figuring what dependencies a package has and
telling the user that an operation effecting that package cannot be
performed until all dependencies are met. For example, installing the
Pingus package could involve the following steps:
- Download the pingus package.
- Try to install it; see the package manager complain about missing
libraries called libClanLib.so and libSDL.so.
- Figure out what packages provide these libraries.
- Download the ClanLib and SDL packages.
- Try to install these libraries; see the package manager complain again
about a library called libHermes.so.1; curse the package manager.
- Repeat steps 3 and 4 for the Hermes package, and install it.
- Finally, install pingus.
Similar scenarios can be found for package removal, since a package
cannot be uninstalled until any and all packages that depend on it are
Package upgrade is similar to installation; it is not enough to simply
get the newest version and install. The newer package might have
different dependencies from the old one, requiring different or new
versions of certain packages.
It's clear that such tasks could and should be performed automatically
by the package manager, not the user, and that's what APT (the
Advanced Package Tool) does. It can install, uninstall, and upgrade
packages, automatically handling dependency calculation and package
download. The same steps above can be performed by APT, as shown
[root@zaphod ~]# apt-get install pingus
Reading Package Lists... Done
Building Dependency Tree... Done
The following extra packages will be installed:
ClanLib Hermes ImageMagick
The following NEW packages will be installed:
ClanLib Hermes ImageMagick pingus
0 packages upgraded, 4 newly installed, 0 to remove and 9 not upgraded.
Need to get 2596kB of archives. After unpacking 9357kB will be used.
Do you want to continue? [Y/n] y
Get:1 ftp://mapi2 latest/conectiva/extra ClanLib 0.5.0-5cl [1087kB]
Get:2 ftp://mapi2 latest/conectiva/extra Hermes 1.3.2-2cl [61.6kB]
Get:3 ftp://mapi2 latest/conectiva/main ImageMagick 5.2.4-3cl [1034kB]
Get:4 ftp://mapi2 latest/conectiva/extra pingus 0.4.1-2cl [413kB]
Fetched 2596kB in 0s (3619kB/s)
Executing RPM (-Uvh)...
Preparing... ########################################### [100%]
1:pingus ########################################### [ 25%]
2:ClanLib ########################################### [ 50%]
3:ImageMagick ########################################### [ 75%]
4:Hermes ########################################### [100%]
Because apt-get makes system maintenance tasks (such as software upgrades)
fully automatic, users can always keep their systems up-to-date. For example,
configuring it to retrieve security updates of the installed packages can be
as simple as requesting a general software upgrade from time-to-time.
APT and RPM
APT was initially written by Debian developers (Brian White, Jason
Gunthorpe, and contributors), and, therefore, it first only supported
Debian systems and its dpkg package manager. Although it has been
written to be fairly independent of the underlying package management
system, nobody had written a RPM backend for it. Instead, many
independent efforts have created different software to perform similar
tasks in systems that use RPM.
autorpm, rpmfind, up2date/RHUN, urpmi/rpmdrake/Mandrake Update, and
many others all do similar tasks. The following table gives a comparative
overview of the features present in each tool:
|Package download ||Yes ||Yes||Yes||Yes ||Yes|
|Depend. resolution ||Yes ||No ||Yes||Yes(1)||Yes(1)|
|Package installation ||Yes ||No ||Yes||No ||Yes|
|Package uninstallation ||Yes ||No ||No ||No ||Yes|
|Package upgrade ||Yes ||Yes||Yes||Yes ||Yes|
|System upgrade ||Yes ||No ||Yes||Yes ||Yes|
|Std.http/ftp server(2) ||Yes ||Yes||No ||No ||Yes|
|Command line interface ||Yes ||Yes||Yes||No ||Yes|
|Curses based interface ||Yes ||No ||No ||No ||No|
|X11 interface ||Yes ||No ||Yes||Yes ||Yes|
|Non-inter. operation ||Yes ||No ||Yes||Yes ||No|
|Package authent. ||Yes(4)||No ||Yes||? ||Yes|
|Mirror authent.(3) ||Yes(4)||? ||? ||? ||?|
|Upgrade importance(5) ||Yes(4)||No ||? ||Yes ||Yes|
- Dependency resolution is available up to a fixed/configurable
number of passes.
- Normally, all tools require a special package index file on the server.
That file contains information about the available packages, but they
are ordinary files downloadable through a modified FTP or HTTP server,
allowing easy setup of mirror sites.
- Package authentication automatically verifies whether the downloaded
package is really what the vendor has provided. Mirror authentication
verifies whether the contents of a mirror is the same as the contents of
the original site.
- This feature was added to the RPM-enabled version of APT, but
has not been ported to the mainstream/official version yet.
- When a package is being upgraded, show what the update is about.
This is useful when the user wants to know whether an update is
security-related or just an enhancement.
APT seems to be better-featured than its RPM-specific counterparts,
and after a quick empirical evaluation, it also seems to be
faster. Because of this, an RPM backend was written for APT, which
enables APT to be used to install RPM packages in RPM-based systems
such as Conectiva, Mandrake, Red Hat, and SuSE. Most, if not all,
third-party tools based on APT can also be ported with relatively
little effort to work with RPM packages.
Some Implementation Details
The most important features of a package manager are common to RPM and
dpkg -- dependencies, versioning, informational metadata, and other
features are present in both -- but certain features that are
exclusive to either did not have a straightforward implementation.
- Deferred configuration:
dpkg keeps track of the state of package installation and configuration;
packages can be tagged as installed (meaning unpacked and configured),
half-installed, not-installed, unpacked, half-configured
(only configuration files remain in the system, from a package that
has been removed but not purged). In a similar way, there are package
selection states and package flags. Package states
allow dpkg to
hand the package configuration task over to
debconf[2,3] and get a
"smooth", interactive (at user-selectable levels), or non-interactive
installation and upgrade. RPM can be considered to
packages in two states: installed and not-installed. The other
states were ignored in the port, since interactive configuration
is not currently being handled. An additional state tag could be
added to RPM, in the event that such a feature is implemented in
- File dependencies
File dependencies is a feature that's present in the RPM format but
not in deb. It allows a package to require specific files, instead
of packages. The problem is that these dependencies are not present
in the list of things provided by the packages. RPM uses information
from the list of files in the packages to handle them. The adopted
solution was to find all files required by packages and add them
to the provides list of the appropriate packages.
The disadvantage of this is the significant growth of the
file, but that problem can be minimized by stripping files that
are known to never appear in file dependencies (they're automatically
detected when RPM is building the package).
- rpmlib dependencies
RPM has some special dependencies for requiring some features that
are not present in some versions of RPM itself. They're not
provided by the RPM package and are treated as a special case by rpmlib,
which individually checks these dependencies against a list of features
compiled into rpmlib. APT handles that by simply ignoring all such
features present in the requires list of packages that rpmlib reports.
- ORed dependencies
This feature is only present in deb, but absence of it in RPM does
not pose any problem for APT.
- Package priority
Package priority is an important feature of deb (at least when
used with APT) that's absent in RPM. Package priorities tell how
important the package is for the system and are used in situations
such as when APT needs to choose which package it should install or
remove to satisfy some dependency. The ideal solution for this problem
would be to add an equivalent tag in RPM, but since backward compatibility
with existing packages is desired, it was decided to use a file containing
a list of all packages and their respective priorities. That file
must list at least the important and essential packages for the
distribution being used. A default priority of "standard" is used for
- Essential packages
The essential tag of deb is used by APT to determine whether a package
can be removed. If the user attempts to remove a package like glibc or
bash, it will issue a warning and ask for confirmation. Again, the
ideal solution would be to add such a tag in RPM, but the current solution
is to mark all packages with a "required" priority as essential.
- Multiple simultaneously installed versions of a package
Debian does not allow two versions of the same packages to be
installed in the system, and APT does not handle that. In that system,
packages that are frequently duplicated, such as the kernel or
ncurses, are provided with different package names, like
ncurses4 and ncurses5. Adding support for that case in APT would require
a substantial amount of work and code rewriting. The ideal
alternative would be
to establish a packaging policy stating that packages that can
be installed concurrently should have different names, but,
again, the question of
backwards compatibility is raised. Therefore, a not-so-elegant workaround
was adopted: the user is required to tell APT what packages are
be duplicated in the system (the most common case of the kernel
by default), and APT will treat each version of such packages as distinct
from the others.
- Architecture variations
Some RPM packages have versions compiled with optimizations that are
specific to a variation of an architecture. For example,
the kernel may have packages compiled for i586 and i686, in addition
to the generic i386 package.
This is handled by detecting what packages have multiple
available "sub-architectures" and treating such packages as
distinct, as in the previous case. The appropriate package, depending
on the specific architecture of the machine, will be used.
- Multiple distributions
Some skeptical critics of the RPM port of APT have raised the
issue of multiple vendors providing RPM packages, while Debian
(supposedly) has a central and unique provider; they think this
would create confusion
and pose a threat to system integrity, due to possible
packages provided by different vendors. Firstly, the fact of having
multiple vendors for packages is not exclusive to RPM-based systems. deb
packages can be obtained from Debian developers, Corel, Stormix, and
whatever other Debian-based distributions may exist [not to
mention all the programmers who provide their own debs for
projects that haven't made it into Debian yet, or for versions
newer than the ones in Debian. -- Ed.].
Secondly, it is trivial to add a check in APT to optionally
refuse installation of packages not built for the same
distribution as the one in use, which makes such claim bogus.
Where to get it
Source code and RPMs for the RPM-enabled version of APT are available
by FTP at Conectiva's FTP site:
or at mirrors like:
A HOWTO about the use of APT in RPM systems and the creation of an
APT repository is available at:
There's a mailing list devoted to the RPM port of APT; to subscribe,
just go to:
The current port of RPM for APT is based on apt 0.3.19 and is
maintained separately from the official version of APT. Effort is
currently being made to add the RPM support changes to the aliencode
branch of the APT CVS, which contains some new features and some new
code to better support different packaging backends. Once that port is
finished, it is hoped that the next major and official releases of APT
will come with RPM support.
raptor -- a graphical frontend
raptor, a graphical frontend intended to be easy to use and to allow
better control of what is upgraded, is being developed. It will
support both RPM and deb systems, and is being written in such a way
that adding support for different toolkits should be straightforward,
although only WINGs (the Window Maker toolkit) is supported at the
Unfortunately, there is already another piece of software with the
same name, so its name will have to be changed. :~(
After full integration of the RPM patches into APT, it will have the
potential to become the standard package management frontend for
Linux, shortening the gap between distributions and reducing
incompatibility across distributions for at least one important system
administration tool. Unlike tools from some other vendors, APT does
not have anything tying it to a particular distribution, not even the
word Conectiva in its name, which hopefully removes some of the common
barriers for its wide acceptance.
The temporarily-forked version of APT is already fully functional and
actually works. Conectiva Linux 6.0 -- the first RPM-based
distribution to support APT -- currently ships with it, and has some
repositories that are available for use with APT. It can be downloaded
I also have news about some people successfully using it under Red Hat
6.x to manage a large network of machines, with a custom and internal
repository of packages. There are also some interesting reports of
people having upgraded RH 5.2 or RH 6.x to Conectiva 6.0, after a
little manual adjustments of some packages (I wouldn't recommend that
procedure to anyone, but apparently it's doable). I've made it work
with Red Hat 7 (which uses RPM 4), but, at the time of this writing, I
have no news about real world uses of it.
- Debian GNU/Linux, "dpkg -- a medium-level package manager for Debian
GNU/Linux", System manual page, section 8.
- Hess, Joey, "An Introduction to Debconf". The Debian Project, 2000.
- Hess, Joey, "The Debconf User's Guide". The Debian Project, 2000.
- Matsuoka, Claudio, "Is it Time to Change RPM?", Freshmeat editorial,
http://freshmeat.net/news/2000/09/16/969163199.html, Sep. 2000.
- Hess, Joey, "A comparison of the deb, rpm, tgz, and slp package formats".
Alfredo K. Kojima has a Computer Science degree and currently works as
a programmer at Conectiva, a
Brazillian Linux distribution vendor. He has worked on projects such
as AfterStep and TkSTEP and leads the Window Maker project. He can be
reached at email@example.com.
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 firstname.lastname@example.org
know what you'd like to write about.