Bug 233713

Summary: RPM upgrade behaviour is inconsistent
Product: Red Hat Enterprise Linux 5 Reporter: Matt Wringe <mwringe>
Component: rpmAssignee: Panu Matilainen <pmatilai>
Status: CLOSED ERRATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 5.0CC: jnovy, msuchy, psklenar
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-20 20:48:33 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 454887    
Bug Blocks:    
Attachments:
Description Flags
two simple test rpms: foo and bar none

Description Matt Wringe 2007-03-23 22:20:37 UTC 
Description of problem:
Rpm handles upgrading of packages in an inconsistent and unintutive manner.

'rpm -i foo.rpm' only install package foo
'rpm -e foo' only remove package foo
'rpm -U foo.rpm' may do more than just install/upgrade package foo

For example, consider a package Foo, and a package Bar that has a virtual
provides on Foo.

On a clean system, 'rpm -U bar.rpm' and then 'rpm -U foo.rpm' will install
packages foo and bar.

If the foo package is updated, 'rpm -U foo-2.0.rpm' will cause bar to be
removed, since bar has a virtual provides on foo. This even occurs if bar has a
virtual provides that is versioned higher than foo.

But if the bar pacakge is updated instead, 'rpm -U bar-2.0.rpm' will not cause
bar to be removed even though bar has a provides on foo.

So we have the following inconsistencies:
1) rpm -U is not just upgrading the provided package, it may also be removing
packages that virtual provides that package. This is not the same behaviour as
the install or remove option which only does an operation on the provided package.

2) when the -U option is used on a clean system (which means it will be doing an
install instead of a upgrade) this will not remove other packages that virtual
provide the package name.

3) when a package is updated using -U, any other packages that have a virtual
provides with the same name will be removed. In this case -U is considering
virtual provides the same as the package name (except ignoring versions)

4) when a package that has a virtual provides is updated using -U only this
package is updated. In this case -U is not considering virtual provides the same
as the package name.

Version-Release number of selected component (if applicable):
I have tested this issue on rpm-4.3.3-18_nonptl (as well as on fc5 with
rpm-4.4.2-15.2). Both behave the same.

How reproducible:
Always reproducible

Steps to Reproduce:
I have created an attachment that contains two very simple test packages: foo
and bar. Package bar has a virtual provides for foo.
1. Build foo and bar rpms
2. rpm -Uvh bar-1.0-1.noarch.rpm
3. rpm -Uvh foo-1.0-1.noarch.rpm
At this point bar and foo should be installed
$ rpm -q foo bar
foo-1.0-1
bar-1.0-1

5. bump the release of foo and rebuild
6. rpm -Uvh foo-1.0-2.noarch.rpm
$ rpm -q foo bar
foo-1.0-2
package bar is not installed

Actual results:
bar will now be deleted from the system

Expected results:
bar should still installed on the system, updating should only update a package
that matches on package name and not on virtual provides.
Comment 1 Matt Wringe 2007-03-23 22:20:37 UTC 
Created attachment 150804 [details]
two simple test rpms: foo and bar
Comment 2 Jeff Johnson 2007-03-26 12:18:22 UTC 
Yes.

rpm -U promises to never erase any package content. Specifically,
neiter old packages nor Obsoletes: are processed.

Feature.

WONTFIX
Comment 3 Jeff Johnson 2007-03-26 12:24:38 UTC 
FYI, rpm-4.4.8 has the following additional uptions to be used with -U,--upgrade:
    --noupgrade      disable erasing old packages
    --noobsoletes    don't erase obsoleted packages

UPSTREAM
Comment 4 Matt Wringe 2007-03-26 14:03:05 UTC 
(In reply to comment #2)
> rpm -U promises to never erase any package content. Specifically,
> neiter old packages nor Obsoletes: are processed.

I am a bit confused by your statement. 'rpm -U foo' will remove package bar from
the system if bar has a virtual provides on foo. Isn't this erasing package content?
Comment 5 Matt Wringe 2007-03-26 14:05:51 UTC 
(In reply to comment #3)
> FYI, rpm-4.4.8 has the following additional uptions to be used with -U,--upgrade:
>     --noupgrade      disable erasing old packages
>     --noobsoletes    don't erase obsoleted packages
> 
> UPSTREAM

How does this help this situation? 
-old packages would match on package name (my example uses two different package
names)
-I am not using obsoletes
Comment 6 Jeff Johnson 2007-03-26 15:04:55 UTC 
Adding --noupgrade prevents rpm from erasing the older package.
Comment 7 Jeff Johnson 2007-03-26 15:06:42 UTC 
FWIW, rpm uses RPMTAG_PROVIDENAME, not RPMTAG_NAME, to determine "newer" vs. "older".

The difference between the two tags is exactly the virtual package implementation.
Comment 8 Matt Wringe 2007-03-26 15:43:44 UTC 
The package getting removed has a higher virtual version then the package being
updated. How is this "older"? 
And for that manner, when I update a package that has a higher virtual provides,
why doesn't the other package get removed?
The same thing I have two packages that both have the same virtual provides,
they never remove one another.

My whole issue here is that the behavior is inconsistent.
RPM only seems to be considering provides names the same as package names when
that package is updated using rpm -U, and even then it ignores versions.

If a package is being installed using rpm -U, it doesn't look to remove the
other pacakges that provide the package name.
If a package is being updated, it doesn't also look to remove every other
package that it has a virtual provides for.
And when comparing it to how other rpm commands work, it is also not consistent.
rpm -e only considered package names, not virtual provides.
Comment 9 Michael Schwendt 2007-04-12 20:19:22 UTC 
Meanwhile, several years old: bug 111071
Comment 10 Jeff Johnson 2007-04-13 01:22:12 UTC 
Yes. For several years (at least) rpm uses RPMTAG_PROVIDENAME, not RPMTAG_NAME. There has been no 
change in rpm behavior in that period of time.
Comment 11 Denise Dumas 2008-07-16 14:14:18 UTC 
The RPM rebase in 5.3 / Fedora 9 includes a fix for this issue.
Comment 12 RHEL Program Management 2008-07-16 14:31:35 UTC 
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.
Comment 16 Panu Matilainen 2008-09-26 06:38:57 UTC 
*** Bug 461165 has been marked as a duplicate of this bug. ***
Comment 18 errata-xmlrpc 2009-01-20 20:48:33 UTC 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0079.html