This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 479608 - rpm -Fvh ignores the architecture when choosing RPMs to freshen
rpm -Fvh ignores the architecture when choosing RPMs to freshen
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: rpm (Show other bugs)
6.0
All Linux
high Severity high
: rc
: ---
Assigned To: Panu Matilainen
: Reopened
Depends On: 171743
Blocks: 627601
  Show dependency treegraph
 
Reported: 2009-01-11 21:25 EST by Jatin Nansi
Modified: 2011-05-19 10:19 EDT (History)
10 users (show)

See Also:
Fixed In Version: rpm-4.8.0-13.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 171743
Environment:
Last Closed: 2011-05-19 10:19:08 EDT
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 Jatin Nansi 2009-01-11 21:25:25 EST
+++ This bug was initially created as a clone of Bug #171743 +++

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.

--- Additional comment from n3npq@mac.com on 2005-11-13 22:20:46 EDT ---



*** This bug has been marked as a duplicate of 88623 ***

--- Additional comment from petrides@redhat.com on 2006-03-21 17:22:38 EDT ---

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


--- Additional comment from petrides@redhat.com on 2006-03-21 17:30:01 EDT ---

*** Bug 176174 has been marked as a duplicate of this bug. ***

--- Additional comment from jcaruso@arenasolutions.com on 2006-03-21 18:50:04 EDT ---

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.


--- Additional comment from pm-rhel@redhat.com on 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.

--- Additional comment from pnasrat@redhat.com on 2006-09-12 09:53:55 EDT ---

Private Developer notes - not for customer:

Real point of contention upstream, recommended upgrade paths are using
up2date/anaconda.  Too much divergence for an update release, suggest evaluating
for a future RHEL release.

--- Additional comment from pm-rhel@redhat.com on 2006-09-12 10:00:05 EDT ---

Development Management has reviewed and declined this request.  You may appeal
this decision by reopening this request. 

--- Additional comment from syeghiay@redhat.com on 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.


--- Additional comment from jcaruso@arenasolutions.com on 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...).


--- Additional comment from dwmw2@redhat.com on 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.

--- Additional comment from bugzilla@redhat.com on 2007-08-21 01:20:44 EDT ---

User pnasrat@redhat.com's account has been closed

--- Additional comment from pmatilai@redhat.com on 2007-08-22 02:33:12 EDT ---

Reassigning to owner after bugzilla made a mess, sorry about the noise...

--- Additional comment from pmatilai@redhat.com on 2007-10-24 06:14:07 EDT ---

*** Bug 88623 has been marked as a duplicate of this bug. ***

--- Additional comment from tao@redhat.com on 2007-11-28 07:12:04 EDT ---

There have been no updates to this issue in the past 28 days. This issue
will now be closed due to inactivity. If this is in error, please reopen
the issue and check to make sure that it is current and in the proper
status. If the issue is something which is on a longer timeline than a
month, please change the status to one of the long term selections to
avoid closure due to inactivity.
This event sent from IssueTracker by AutoCloser  [Production Support]
 issue 90303

--- Additional comment from tao@redhat.com on 2008-04-17 07:10:38 EDT ---

There have been no updates to this issue in the past 28 days. This issue
will now be closed due to inactivity. If this is in error, please reopen
the issue and check to make sure that it is current and in the proper
status. If the issue is something which is on a longer timeline than a
month, please change the status to one of the long term selections to
avoid closure due to inactivity.
This event sent from IssueTracker by AutoCloser  [GSS-APAC Australia/New
Zealand Support]
 issue 135898

--- Additional comment from kengert@redhat.com on 2008-04-17 10:53:31 EDT ---

I think it's not good that bugs get automatically closed.

This is a confirmed bug.
Nobody has worked on this bug.
It's wrong to assume it can be closed.

So, the previous comment suggests "If the issue is something which is on a
longer timeline than a month, please change the status to one of the long term
selections"

Which status value should be used for that?


--- Additional comment from fedora-triage-list@redhat.com on 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

--- Additional comment from dash@redhat.com on 2009-01-06 17:28:56 EDT ---

I've taken ownership of a crm #1810460 from a fairly big customer here on this so interested in the progress on a fix for this issue.  Also added another IT to the list.

--- Additional comment from dash@redhat.com on 2009-01-06 17:39:33 EDT ---

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)

--- Additional comment from jcaruso@arenasolutions.com on 2009-01-07 15:03:07 EDT ---

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 1 RHEL Product and Program Management 2009-02-05 18:33:42 EST
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.
Comment 2 RHEL Product and Program Management 2010-07-15 11:01:44 EDT
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
Comment 3 Bryan Mason 2010-08-31 18:39:16 EDT
For what it's worth, this doesn't appear to be fixed in the current RHEL 6.0 Beta (of course maybe it wasn't expected to be fixed, in which case I'm just be reporting the obvious):

    # rpm -qa rpm
    rpm-4.8.0-12.el6.x86_64

    # cat /etc/redhat-release 
    Red Hat Enterprise Linux Workstation release 6.0 Beta (Santiago)

    # ls hunspell/1.2.8-16/
    hunspell-1.2.8-16.el6.i686.rpm  hunspell-1.2.8-16.el6.x86_64.rpm

    # rpm -qa hunspell
    hunspell-1.2.8-14.el6.x86_64

    # rpm -Fvh hunspell/1.2.8-16/*.rpm
    warning: hunspell/1.2.8-16/hunspell-1.2.8-16.el6.i686.rpm: Header V3 
    RSA/SHA256 Signature, key ID fd431d51: NOKEY
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [ 50%]
       2:hunspell           ########################################### [100%]

    # rpm -qa hunspell
    hunspell-1.2.8-16.el6.i686
    hunspell-1.2.8-16.el6.x86_64

And...

    # rpm -q hunspell
    hunspell-1.2.8-14.el6.x86_64
    hunspell-1.2.8-14.el6.i686

    # rpm -Fvh hunspell/1.2.8-16/hunspell-1.2.8-16.el6.i686.rpm
    warning: hunspell/1.2.8-16/hunspell-1.2.8-16.el6.i686.rpm: Header V3 
    RSA/SHA256 Signature, key ID fd431d51: NOKEY
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [100%]

    # rpm -Fvh hunspell/1.2.8-16/hunspell-1.2.8-16.el6.x86_64.rpm
    warning: hunspell/1.2.8-16/hunspell-1.2.8-16.el6.x86_64.rpm: Header V3 
    RSA/SHA256 Signature, key ID fd431d51: NOKEY

    # rpm -q hunspell
    hunspell-1.2.8-14.el6.x86_64
    hunspell-1.2.8-16.el6.i686
Comment 7 Miroslav Vadkerti 2011-01-27 05:42:01 EST
Panu, isn't this the a part of the issue reported by bug 553108?
Comment 8 Panu Matilainen 2011-01-27 05:45:59 EST
Yes, bug 553108 is actually a duplicate of this.
Comment 10 Bryan Mason 2011-03-21 15:52:30 EDT
Seems to be working in rpm-4.8.0-16.el6:

When only one architecture is installed, running "rpm -F" doesn't install new architectures.

    [root@test-new-stuff bz479608]# rpm -q rpm
    rpm-4.8.0-16.el6.x86_64

    [root@test-new-stuff bz479608]# rpm -ivh hunspell-1.2.8-14.el6.x86_64.rpm 
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [100%]

    [root@test-new-stuff bz479608]# rpm -q hunspell
    hunspell-1.2.8-14.el6.x86_64

    [root@test-new-stuff hunspell-rpms]# rpm -Fvh hunspell-1.2.8-16.el6.*.rpm
    warning: hunspell-1.2.8-16.el6.i686.rpm: Header V3 RSA/SHA256 Signature, 
    key ID fd431d51: NOKEY
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [100%]

    [root@test-new-stuff bz479608]# rpm -q hunspell
    hunspell-1.2.8-16.el6.x86_64

    [root@test-new-stuff bz479608]# rpm -e hunspell.x86_64

And if only one architecture has been updated, rpm now freshens the other architecture when asked to do so:

    [root@test-new-stuff bz479608]# rpm -ivh hunspell-1.2.8-14.el6.*.rpm
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [ 50%]
       2:hunspell           ########################################### [100%]

    [root@test-new-stuff bz479608]# rpm -q hunspell
    hunspell-1.2.8-14.el6.x86_64
    hunspell-1.2.8-14.el6.i686

    [root@test-new-stuff bz479608]# rpm -Fvh hunspell-1.2.8-16.el6.i686.rpm 
    warning: hunspell-1.2.8-16.el6.i686.rpm: Header V3 RSA/SHA256 Signature, 
    key ID fd431d51: NOKEY
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [100%]

    [root@test-new-stuff bz479608]# rpm -q hunspell
    hunspell-1.2.8-14.el6.x86_64
    hunspell-1.2.8-16.el6.i686

    [root@test-new-stuff bz479608]# rpm -Fvh hunspell-1.2.8-16.el6.x86_64.rpm 
    warning: hunspell-1.2.8-16.el6.x86_64.rpm: Header V3 RSA/SHA256 Signature, 
    key ID fd431d51: NOKEY
    Preparing...            ########################################### [100%]
       1:hunspell           ########################################### [100%]

    [root@test-new-stuff bz479608]# rpm -q hunspell
    hunspell-1.2.8-16.el6.i686
    hunspell-1.2.8-16.el6.x86_64

Cool.
Comment 12 errata-xmlrpc 2011-05-19 10:19:08 EDT
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-2011-0739.html

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