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.
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
Provides: line in the specfile.)