Articles / An RPM port of APT

An RPM port of APT

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.

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:

  1. Download the pingus package.
  2. Try to install it; see the package manager complain about missing libraries called libClanLib.so and libSDL.so.
  3. Figure out what packages provide these libraries.
  4. Download the ClanLib and SDL packages.
  5. Try to install these libraries; see the package manager complain again about a library called libHermes.so.1; curse the package manager.
  6. Repeat steps 3 and 4 for the Hermes package, and install it.
  7. 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 YesYesYes Yes
Depend. resolution Yes No YesYes(1)Yes(1)
Package installation Yes No YesNo Yes
Package uninstallation Yes No No No Yes
Package upgrade Yes YesYesYes Yes
System upgrade Yes No YesYes Yes
Std.http/ftp server(2) Yes YesNo No Yes
Command line interface Yes YesYesNo Yes
Curses based interface Yes No No No No
X11 interface Yes No YesYes Yes
Non-inter. operation Yes No YesYes No
Package authent. Yes(4)No Yes? Yes
Mirror authent.(3) Yes(4)? ? ? ?
Upgrade importance(5) Yes(4)No ? Yes Yes
  1. Dependency resolution is available up to a fixed/configurable number of passes.
  2. 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.
  3. 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.
  4. This feature was added to the RPM-enabled version of APT, but has not been ported to the mainstream/official version yet.
  5. 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

  1. Debian GNU/Linux, "dpkg -- a medium-level package manager for Debian GNU/Linux", System manual page, section 8.
  2. Hess, Joey, "An Introduction to Debconf". The Debian Project, 2000.
  3. Hess, Joey, "The Debconf User's Guide". The Debian Project, 2000.
  4. Matsuoka, Claudio, "Is it Time to Change RPM?", Freshmeat editorial, http://freshmeat.net/news/2000/09/16/969163199.html, Sep. 2000.
  5. Hess, Joey, "A comparison of the deb, rpm, tgz, and slp package formats". http://www.kitenet.net/~joey/pkg-comp/, 2000.

  6. 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!

    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 jeff.covey@freshmeat.net know what you'd like to write about.

Recent comments

28 Apr 2005 06:55 Avatar shoes

RPM-based distributions
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 (http://www.3e6.com)

14 Dec 2000 15:57 Avatar itsbruce

One in the eye for the RHN


Hopefully this will give Red Hat users the idea that the Red Hat Network is one big rip off. After all, the big selling point for RHN isn't the priority ftp but the supposed easing of maintenance and upgrading. Now users of rpm-based distributions may be able to get that for free, as Debian users can.

Of course, apt is only half the story. Decent package policy is the other half. Not to mention that too many of the RH admin scripts are disgracefully lame or broken.

Apt was only half of what drew me from RH to Debian. The other was sensible config decisions. Red Hat just don't listen enough to their users - I used to be on the RH mailing lists and I know there were enough people trying to help out with the dumb config errors.

Oh yes, and timecop is an idiot.

13 Dec 2000 21:31 Avatar fredlwm

Re: timecop
Well, Timecop isn't totally wrong, I can agree with him in various parts, let's see where I just can't:


[Re: how about more additions...]

> I am surprised you have an email @debian.org. People like you should
> never even touch linux. Go download your precompiled binary packages
> for your other favorite OS. At least they all come in one format, .exe

I'd if it was @slackware.com

[Precompiled Binary Package problem]

> Linux software, be it in a precompiled binary package or in form or
> source code, SUCKS!

Excuse-me, but you use what?

> With precompiled binary packages you get all the benefits of shit
> software plus complete inability to debug it.

Are you sure they strip all binaries?

> In my particular case I don't want to install all the damn mexican
> and bolivian and what the hell ever translations.

Me too, nor from sources. cd po;rm -f *.po *.gmo *.mo FYI, there are no
specific Mexican and Bolivian translations. They speak spanish, so
guess...

> The precompiled binary package will happily install those for you.

Yes, as it should.

> Suppose I want to install a new and stupid GUI program into a
> completely separate directory, so nuking it would be real simple?

I think you can do that.

> GUI Linux distributions aka RedHat aka Mundake aka Conectiva (who the
> hell would trust some brazilian linux distribution in the first place?
> I would imagine transfer speeds from their download site be about 1~2
> k/sec) promote even more stupidity.

Really bad. You forgot who wrote Window Maker is a Brazilian (of course,
if you're not the real timecop dockapps...).

Well, I don't like or dislike those package managers or binary
packages. They're good for newbies, lazy, and "administrators" with no
free time. At least if I could trust them...

13 Dec 2000 09:55 Avatar blades

Re: timecop
(After gettimg up from ROTFLMAO:)

Just because he has written some dockapps doesn't mean he's civilized. Nor timecop.

I think you should consider only the article and not the writer's name (There's no killfiles here (yet?)), look at the content and see that it's not really worth bothering with. You can't start arguing with them all and you can't turn their heads.
If you want to respond to that kind of things, do it in a civilized manner and balance out a bad post with a sensible one. If you're really into it, go to usenet ;).


Fol rol de ol rol..

(*plonk* suppressed)

12 Dec 2000 13:04 Avatar fredlwm

timecop
The same timecop from #LinuxWarez at EFNet?

Screenshot

Project Spotlight

Kigo Video Converter Ultimate for Mac

A tool for converting and editing videos.

Screenshot

Project Spotlight

Kid3

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