Bug 171743 - rpm -Fvh ignores the architecture when choosing RPMs to freshen
rpm -Fvh ignores the architecture when choosing RPMs to freshen
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: rpm (Show other bugs)
rawhide
All Linux
medium Severity high
: ---
: ---
Assigned To: Panu Matilainen
Mike McLean
: Reopened
: 88623 176174 (view as bug list)
Depends On:
Blocks: 176344 multilib 479608
  Show dependency treegraph
 
Reported: 2005-10-25 16:38 EDT by John Caruso
Modified: 2011-01-19 08:40 EST (History)
8 users (show)

See Also:
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 08:40:39 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description John Caruso 2005-10-25 16:38:03 EDT
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.
Comment 1 Jeff Johnson 2005-11-13 22:20:46 EST

*** This bug has been marked as a duplicate of 88623 ***
Comment 2 Ernie Petrides 2006-03-21 17:22:38 EST
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
Comment 3 Ernie Petrides 2006-03-21 17:30:01 EST
*** Bug 176174 has been marked as a duplicate of this bug. ***
Comment 4 John Caruso 2006-03-21 18:50:04 EST
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.
Comment 5 RHEL Product and Program Management 2006-08-18 13:08:24 EDT
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 7 RHEL Product and Program Management 2006-09-12 10:00:05 EDT
Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 
Comment 8 Suzanne Yeghiayan 2007-04-13 14:05:20 EDT
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.
Comment 9 John Caruso 2007-04-13 14:13:43 EDT
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...).
Comment 10 David Woodhouse 2007-04-14 03:22:30 EDT
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.
Comment 11 Red Hat Bugzilla 2007-08-21 01:20:44 EDT
User pnasrat@redhat.com's account has been closed
Comment 12 Panu Matilainen 2007-08-22 02:33:12 EDT
Reassigning to owner after bugzilla made a mess, sorry about the noise...
Comment 13 Panu Matilainen 2007-10-24 06:14:07 EDT
*** Bug 88623 has been marked as a duplicate of this bug. ***
Comment 17 Bug Zapper 2008-05-13 22:03:00 EDT
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
Comment 19 David Ash 2009-01-06 17:39:33 EST
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)
Comment 20 John Caruso 2009-01-07 15:03:07 EST
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.
Comment 21 Bug Zapper 2009-06-09 05:08:19 EDT
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
Comment 23 Bug Zapper 2010-04-27 07:37:55 EDT
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
Comment 24 David Ash 2010-04-27 08:17:10 EDT
should i change this to rawhide or f12 or f13?
Comment 25 Bug Zapper 2010-11-04 08:18:07 EDT
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
Comment 26 John Caruso 2010-11-04 13:40:32 EDT
Yes, please change it to whatever version of Rawhide you need to.  Thanks.
Comment 29 Panu Matilainen 2011-01-19 08:40:39 EST
Fixed in rawhide as of rpm-4.9.0-0.beta1.1.fc15.

Note You need to log in before you can comment on or make changes to this bug.