12:49 UTC

add comment

An RPM port of APT
by Alfredo K. Kojima, in Editorials - Sat, Dec 2nd 2000 23:59 UTC

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.

Copyright notice: All reader-contributed material on freshmeat.net is the property and responsibility of its author; for reprint rights, please contact the author directly.

Why APT?

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 removed first.

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 below:

[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:

APT autorpm rpmfind up2date/RHUN *drake*/urpmi

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 and config-files(-installed) (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^[1]. 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^[4]. RPM can be considered to recognize 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 the future.
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 package index 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 other packages.
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 concurrently 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 kernel2_2_17, or 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 expected to be duplicated in the system (the most common case of the kernel is handled 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 incompatibilities in 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:
ftp://ftp.conectiva.com/pub/conectiva/EXPERIMENTAL/apt/

or at mirrors like:
ftp://rufus.w3.org/linux/conectiva/EXPERIMENTAL/apt/

A HOWTO about the use of APT in RPM systems and the creation of an APT repository is available at:
http://bazar.conectiva.com.br/~godoy/apt-howto/

There's a mailing list devoted to the RPM port of APT; to subscribe, just go to:
http://distro.conectiva.com.br/mailman/listinfo/apt-rpm/

ToDo

aliencode port

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 moment.

Unfortunately, there is already another piece of software with the same name, so its name will have to be changed. :~(

Conclusion

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 at:

ftp://rufus.w3.org/linux/conectiva/6.0/
or
ftp://ftp.conectiva.com/pub/conectiva/6.0/

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.

References

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". http://www.kitenet.net/~joey/pkg-comp/, 2000.

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 kojima@conectiva.com.br.

T-Shirts and Fame!

ThinkGeek

jeff.covey@freshmeat.net

[Comments are disabled]

Referenced categories

Topic :: System :: Archiving :: Packaging
Topic :: System :: Software Distribution
Topic :: System :: Software Distribution Tools

Referenced projects

AutoRPM - An RPM auto-installer and/or FTP mirrorer.
Debian GNU/Linux - The Universal Operating System.
dpkg - A package maintenance system for Debian GNU/Linux.
Mandriva - A graphically-oriented popular Linux distribution.
openSUSE - A Linux distribution.
Red Hat Linux - The Red Hat Linux distribution.
RPM - The RPM package management system.
rpm2html - Utilities to create HTML pages about RPM packages.

Comments

[»] RPM-based distributions
by shoes - Apr 28th 2005 06:55:16

Hopefully, RPM-based distributions will decide to switch to this. There's another package manager named yup that has similar functionality AFAIK (though I haven't gotten to do a real-world test of it). The only thing is, it keeps a totally separate database both on mirrors and on the client machine, separate from the RPM databases. I don't know if that's what apt-get does, but I hope not. :-) It'd be nice to have the same benefits on an RPM system. shoes