Bug 111071 - unexpected removal of package upon upgrade / inconsistent behaviour
unexpected removal of package upon upgrade / inconsistent behaviour
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Paul Nasrat
Fedora Extras Quality Assurance
https://bugzilla.fedora.us/show_bug.c...
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-11-26 18:15 EST by Michael Schwendt
Modified: 2014-01-21 17:48 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-18 04:38:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Michael Schwendt 2003-11-26 18:15:07 EST
[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
Comment 1 Seth Vidal 2003-11-26 18:37:59 EST
update

it is reproducible with plain rpm.

use rpm -Uvh not rpm -ivh and the bug is reproducible with normal rpm.
Comment 2 Michael Schwendt 2003-11-26 18:57:29 EST
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.
Comment 3 Jeff Johnson 2003-11-30 11:23:25 EST
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.
Comment 4 Michael Schwendt 2003-11-30 12:48:17 EST
Please comment on comment 2. Thank you.
Comment 5 Jeff Johnson 2003-11-30 18:36:22 EST
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.
Comment 6 Rex Dieter 2004-03-15 12:39:41 EST
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?  
Comment 7 Axel Thimm 2004-03-15 12:56:30 EST
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.
Comment 8 Jindrich Novy 2007-08-18 04:14:38 EDT
Reopening as this should be reconsidered to fix it again.
Comment 9 Panu Matilainen 2007-08-18 04:38:17 EDT
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. 

Note You need to log in before you can comment on or make changes to this bug.