Red Hat Bugzilla – Bug 233713
RPM upgrade behaviour is inconsistent
Last modified: 2009-01-20 15:48:33 EST
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.
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
5. bump the release of foo and rebuild
6. rpm -Uvh foo-1.0-2.noarch.rpm
$ rpm -q foo bar
package bar is not installed
bar will now be deleted from the system
bar should still installed on the system, updating should only update a package
that matches on package name and not on virtual provides.
Created attachment 150804 [details]
two simple test rpms: foo and bar
rpm -U promises to never erase any package content. Specifically,
neiter old packages nor Obsoletes: are processed.
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
(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?
(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
How does this help this situation?
-old packages would match on package name (my example uses two different package
-I am not using obsoletes
Adding --noupgrade prevents rpm from erasing the older package.
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.
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.
Meanwhile, several years old: bug 111071
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.
The RPM rebase in 5.3 / Fedora 9 includes a fix for this issue.
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
*** Bug 461165 has been marked as a duplicate of this bug. ***
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.