A surprise with the Provides header in RPM

Normally, one of the things RPM bases dependencies on is package names. The problem with doing only this is packages that want to depend on capabilities instead of specific packages; for example, that there is some mailer installed, not specifically that Sendmail is installed. To deal with this, RPM introduced the Provides: directive, which lets an RPM package tell the overall RPM system that it is providing something that is not obvious from its name, its files, and so on.

In implementing this, RPM has chosen to not represent Provides separately in its internal databases. When a package Provides something, to RPM that package is that something, as much as it is its regular name; effectively the same RPM package is two or more RPMs. This turns out to have an interesting and surprising consequence, best illustrated with an anecdote.

A while ago when Fedora switched firmly to CUPS, we decided that while we would use CUPS on the clients we would keep using LPRng for our print server. Since Fedora no longer packaged LPRng, I built the RPM myself and tried to install it; as is my usual habit, I used rpm's -U option. Things promptly blew up screaming that I was trying to remove the CUPS libraries that half the known Gnomeiverse depended on.

The problem turned out to be that CUPS had (at that time) a Provides that said it provided 'LPRng = 3.8.15-3'. Thus as far as RPM was concerned, CUPS was LPRng version 3.8.15-3, and since I was doing an upgrade install of a more recent version, it needed to remove the old version, removing all of those shared libraries that programs needed.

(Using 'rpm -i' instead would not have really helped, because we would have run into trouble the first time we needed to upgrade our own LPRng package. My solution was to rebuild the CUPS RPM without that Provides: line in the specfile.)