[As posted to fedora-devel-list and bugzilla.fedora.us (see URL).] Demonstration uses two packages from fedora.us "stable" repository. Installing package "gpgme03" and then "gpgme" with "yum" erases gpgme03, although gpgme does not obsolete gpgme03: # rpm -q yum yum-2.0.4-2 First we make sure, neither "gpgme" nor "gpgme03" is installed: # rpm -qa 'gpgme*' | xargs rpm -e Then we install gpgme03: # yum -y install gpgme03 Gathering header information file(s) from server(s) Server: Fedora Core 1 - i386 - Base Server: Fedora.us stable Server: Fedora Core 1 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: gpgme03 0.3.15-0.fdr.2.1.i386] gpgme03 100 % done 1/1 Installed: gpgme03 0.3.15-0.fdr.2.1.i386 Transaction(s) Complete And then gpgme: # yum -y install gpgme Gathering header information file(s) from server(s) Server: Fedora Core 1 - i386 - Base Server: Fedora.us stable Server: Fedora Core 1 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: gpgme 0.4.0-0.fdr.2.1.i386] Getting gpgme-0.4.0-0.fdr.2.1.i386.rpm gpgme 100 % done 1/2 * Erasing: gpgme03 2/2 Installed: gpgme 0.4.0-0.fdr.2.1.i386 Transaction(s) Complete Why does it erase gpgme03? There is no "Obsoletes:" listed in gpgme. It is reproducible with Red Hat Linux 9. Yum maintainer believes it is a bug in rpm-python. It is not reproducible with plain rpm (see below). Could it be that "gpgme" is treated as an update to "gpgme03" by accident? Maybe because both packages provides "gpgme = %epoch:%version-%release"? $ rpm -q --provides gpgme03 gpgme = 0:0.3.15-0.fdr.2.1 libgpgme.so.6 gpgme03 = 0:0.3.15-0.fdr.2.1 $ rpm -q --provides gpgme libgpgme.so.10 gpgme = 0:0.4.0-0.fdr.2.1 On the contrary: # rpm -ivh gpgme03-0.3.15-0.fdr.2.1.i386.rpm Preparing... ########################################### [100%] 1:gpgme03 ########################################### [100%] # rpm -ivh gpgme-0.4.0-0.fdr.2.1.i386.rpm Preparing... ########################################### [100%] 1:gpgme ########################################### [100%] # rpm -qa 'gpgme*' gpgme03-0.3.15-0.fdr.2.1 gpgme-0.4.0-0.fdr.2.1 No problems with "rpm" as demonstrated. It doesn't erase "gpgme03" when it installes "gpgme". Additional information: Installing both packages at once with yum, does not reproduce the problem either. Version-Release number of selected component (if applicable): rpm-python-4.2.1-0.30 How reproducible: Always
update it is reproducible with plain rpm. use rpm -Uvh not rpm -ivh and the bug is reproducible with normal rpm.
If both packages are -Uvh'ed at once, there are no conflicts or removals: # rpm -Uvh gpgme03-0.3.15-0.fdr.2.1.i386.rpm gpgme-0.4.0-0.fdr.2.1.i386.rpm Preparing... ########################################### [100%] 1:gpgme ########################################### [ 50%] 2:gpgme03 ########################################### [100%] # rpm -qa 'gpgme*' gpgme-0.4.0-0.fdr.2.1 gpgme03-0.3.15-0.fdr.2.1 [...] Similary, if "rpm -ivh gpgme*" is run first and then "rpm -Uvh gpgme03*", it works without problems/warnings/errors either.
Hmmm, gpgme03 has (afaict) Provides: gpgme = 0:0.3.15-0.fdr.2.1 So gpgme03 is erased when gpgme is upgraded. This is the implemented and desired behavior, not gonna change.
Please comment on comment 2. Thank you.
What, that you can get different behavior if both are included in same transaction? Yes, update behavior is defined against installed, not added, packages, and including both on same CLI will install both pkgs.
IMO, this behavior is certainly unexpected, and annoying in the least. (since it changes behavior from previous versions). What's the point of having separate Obsoletes and Provides tags then? Is Obsoletes predecated?
With the new behaviour of upgrading on virtual provides, there is currently no mechanism for having compatibility packages provide a standardized resource that is being required by another package (because they get upgraded upon that exposed resource entity). So any compatibility cycling (think new autoconf/automake) requires rewriting of dependent packages. Instead packages depending on for instance autoconf/automake could simply have had BuildRequires: autoconf >= 2.53, autoconf < 2.59 (similar for automake, libtool, gcc, python, etc.) Ideally packages exitsing in multiple versions would a) either have a common name, but be identified as non-upgradable (like some resolvers deal with "kernel" packages), or b) be uniquified by adding version suffixes to the rpm name-tag of the package, but still provide a common and versioned entity string (e.g. automake14 and automake16 provide automake = ...). a) would require automation within rpm, because keeping an external list of packages to be installed, not upgraded, is a bad bookkeeping practice (this could be something like Provides: never-upgrade, which rpm's upgrade mechanism should respect). b) is broken with rpm >= 4.2.1 because the common entity is taken into package upgrade consideration, removing all older packages.
Reopening as this should be reconsidered to fix it again.
Rpm 4.4.2.1 reverts the implicit obsoletion on provides behavior. So it's already fixed in rawhide, and update for F7 and FC6 is in updates-testing.