Bug 171743
| Summary: | rpm -Fvh ignores the architecture when choosing RPMs to freshen | |||
|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | John Caruso <jcaruso> | |
| Component: | rpm | Assignee: | Panu Matilainen <pmatilai> | |
| Status: | CLOSED RAWHIDE | QA Contact: | Mike McLean <mikem> | |
| Severity: | high | Docs Contact: | ||
| Priority: | medium | |||
| Version: | rawhide | CC: | chris.ricker, dash, jko, jnansi, kengert, pmatilai, rrajaram, tao | |
| Target Milestone: | --- | Keywords: | Reopened | |
| Target Release: | --- | |||
| Hardware: | All | |||
| OS: | Linux | |||
| Whiteboard: | ||||
| Fixed In Version: | rpm-4.9.0-0.beta1.1.fc15 | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 479608 (view as bug list) | Environment: | ||
| Last Closed: | 2011-01-19 13:40:39 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: | ||||
| Bug Blocks: | 176344, 235752, 479608 | |||
*** This bug has been marked as a duplicate of 88623 *** Reopening this bug report at the request of John Caruso. John, please also contact Red Hat Customer Support to register this problem. Since this bug report is already open, ask them to link the newly created Issue Tracker ticket to this BZ so that this bug report will get a proper priority score. Thanks in advance. -ernie *** Bug 176174 has been marked as a duplicate of this bug. *** Thanks, Ernie. I've opened service request 845968 via RHN support and asked them to create an issue tracker ticket and link it to this bug, as you requested. 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. Development Management has reviewed and declined this request. You may appeal this decision by reopening this request. Unfortunately we are unable to address this request in an update release. Changed status back to CLOSED/WONTFIX for RHEL 4.5. If you still would like this issue addressed, please reopen this bugzilla and request it be proposed for RHEL 6.0. As per Suzanne's comment, please consider making this change as of RHEL 6.0. While the original bug was filed against RHEL4, I'm completely agnostic as to where or how a fix fits within Redhat's release model; I'd just like to see the core issue addressed. Feel free to tweak the bug settings so that it won't show up as a blocker for RHEL 4.5 (assuming that's the problem...). I'll refile it against Fedora; once fixed in Fedora it will be OK in RHEL6 too. There are a bunch of issues with our current multilib setup which need improving; this is just one of them. User pnasrat's account has been closed Reassigning to owner after bugzilla made a mess, sorry about the noise... *** Bug 88623 has been marked as a duplicate of this bug. *** Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Hi, any progress on this? Should this be in Fedora 9 still?
Also here is another scenario that can run into this problem due to ARCH being ignored. Basically when you have 2 arch of the same package and do an rpm -F of 2 newer versions in of the same arch one command it succeeds, though if you do one arch at a time (ie. in 2 separate commands), the first will succeed but the 2nd will fail due to arch being ignored and only checking the version:
#rpm -Fvh alsa-lib-1.0.6-5/*.rpm
Though one at a time fails due to freshen doing version check only:
# rpm -Fvh alsa-lib-1.0.6-5/alsa-lib-1.0.6-5.RHEL4.i386.rpm
# rpm -Fvh alsa-lib-1.0.6-5/alsa-lib-1.0.6-5.RHEL4.x86_64.rpm
Steps to reproduce on rhel4:
# rpm -q rpm
rpm-4.3.3-26_nonptl
# rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" alsa-lib
alsa-lib-1.0.6-4.x86_64
alsa-lib-1.0.6-4.i386
# rpm -Fvh alsa-lib-1.0.6-5/*.rpm
Preparing... ########################################### [100%]
1:alsa-lib ########################################### [ 50%]
2:alsa-lib ########################################### [100%]
# rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" alsa-lib
alsa-lib-1.0.6-5.RHEL4.x86_64
alsa-lib-1.0.6-5.RHEL4.i386
# rpm -e alsa-lib-1.0.6-5.RHEL4.x86_64
alsa-lib-1.0.6-5.RHEL4.i386
# rpm -ivh alsa-lib-1.0.6-4/*.rpm
Preparing... ########################################### [100%]
1:alsa-lib ########################################### [ 50%]
2:alsa-lib ########################################### [100%]
# rpm -Fvh alsa-lib-1.0.6-5/alsa-lib-1.0.6-5.RHEL4.i386.rpm
Preparing... ########################################### [100%]
1:alsa-lib ########################################### [100%]
# rpm -Fvh alsa-lib-1.0.6-5/alsa-lib-1.0.6-5.RHEL4.x86_64.rpm
# rpm -q --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" alsa-lib
alsa-lib-1.0.6-4.x86_64
alsa-lib-1.0.6-5.RHEL4.i386
(the last "rpm -F" above failed to update though had a return code of 0 meaning freshen thought it didn't need updating)
And here's another scenario, in which an RPM for an architecture that's not currently installed gets added by an rpm -Fvh command (in addition to the correct architecture's RPM being freshened):
----- 8< ----------------------------------------------
# alias rpmarch='rpm --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n"'
# rpmarch -qa libxml2
libxml2-2.6.16-12.x86_64
# ls -1 libxml2*.rpm
libxml2-2.6.16-12.6.i386.rpm
libxml2-2.6.16-12.6.x86_64.rpm
# rpm -Fvh libxml2*.rpm
Preparing... ########################################### [100%]
1:libxml2 ########################################### [ 50%]
2:libxml2 ########################################### [100%]
# rpmarch -qa libxml2
libxml2-2.6.16-12.6.i386
libxml2-2.6.16-12.6.x86_64
----- 8< ----------------------------------------------
So we start out with one libxml2 RPM and end up with two (clearly a bug for freshen). This is a real-world example--I just had it happen on numerous machines, requiring me to hunt down and remove the extraneous i386 RPM wherever it had been installed. In fact, this is one of the most common cases I have to work around thanks to this bug.
And as long as I'm here, this is broken (and related) as well:
----- 8< ----------------------------------------------
# rpmarch -qa libxml2
libxml2-2.6.16-12.6.x86_64
# rpm -e libxml2-2.6.16-12.6.i386
# rpm -e bogus-libxml2-2.6.16-12.6.i386
error: package bogus-libxml2-2.6.16-12.6.i386 is not installed
----- 8< ----------------------------------------------
The first "rpm -e" command doesn't produce an error message even though the specified package isn't installed.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping should i change this to rawhide or f12 or f13? This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping Yes, please change it to whatever version of Rawhide you need to. Thanks. Fixed in rawhide as of rpm-4.9.0-0.beta1.1.fc15. |
Description of problem: rpm -Fvh ignores the architecture when choosing RPMs to freshen Version-Release number of selected component (if applicable): rpm-4.3.3-9_nonptl.x86_64 How reproducible: Install just one architecture version of an RPM which has multiple architecture versions, wait for an update to that RPM, then do an "rpm -Fvh" using the new version of the RPM but for the wrong architecture; RPM will incorrectly see it as being an update to the RPM architecture which is actually installed. Expected results: RPM should respect the architecture when freshening packages. Additional info: Here's an example: ------ 8< ----------------------------------------------------------- # rpm --queryformat "%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}\n" -q pam pam-0.77-66.5.x86_64 # ll pam-0.77-66.11.* -rw-r--r-- 1 root root 1927634 Sep 1 15:58 pam-0.77-66.11.i386.rpm -rw-r--r-- 1 root root 2005715 Sep 1 15:58 pam-0.77-66.11.x86_64.rpm # rpm -Fvh --test pam-0.77-66.11.x86_64.rpm Preparing... ########################################### [100%] # rpm -Fvh --test pam-0.77-66.11.i386.rpm error: Failed dependencies: libcrack.so.2 is needed by pam-0.77-66.11.i386 libglib-2.0.so.0 is needed by pam-0.77-66.11.i386 libselinux.so.1 is needed by pam-0.77-66.11.i386 ------ 8< ----------------------------------------------------------- The last command in that sequence ("rpm -Fvh --test pam-0.77-66.11.i386.rpm") should produce no output, because RPM should be able to determine that the candidate RPM in that case does not match the architecture of the installed pam RPM (it is for i386, not x86_64). This is potentially a very serious bug, since it may lead to a critical x86_64 RPM being replaced (incorrectly) by an i386 update for the same RPM, and thus seriously impairing a system.