Bug 111071 - unexpected removal of package upon upgrade / inconsistent behaviour
Summary: unexpected removal of package upon upgrade / inconsistent behaviour
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: rpm   
(Show other bugs)
Version: rawhide
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Paul Nasrat
QA Contact: Fedora Extras Quality Assurance
URL: https://bugzilla.fedora.us/show_bug.c...
Whiteboard:
Keywords: Reopened
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-11-26 23:15 UTC by Michael Schwendt
Modified: 2014-01-21 22:48 UTC (History)
5 users (show)

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


Attachments (Terms of Use)

Description Michael Schwendt 2003-11-26 23:15:07 UTC
[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 23:37:59 UTC
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 23:57:29 UTC
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 16:23:25 UTC
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 17:48:17 UTC
Please comment on comment 2. Thank you.

Comment 5 Jeff Johnson 2003-11-30 23:36:22 UTC
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 17:39:41 UTC
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 17:56:30 UTC
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 08:14:38 UTC
Reopening as this should be reconsidered to fix it again.

Comment 9 Panu Matilainen 2007-08-18 08:38:17 UTC
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.