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.
Created attachment 150804 [details] two simple test rpms: foo and bar
Yes. rpm -U promises to never erase any package content. Specifically, neiter old packages nor Obsoletes: are processed. Feature. WONTFIX
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
(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 > > 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
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 release.
*** 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. http://rhn.redhat.com/errata/RHBA-2009-0079.html