Bug 479608

+++ 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 on 2005-11-13 22:20:46 EDT ---



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

--- Additional comment from petrides 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 on 2006-03-21 17:30:01 EDT ---

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

--- Additional comment from jcaruso 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 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 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 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 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 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 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 on 2007-08-21 01:20:44 EDT ---

User pnasrat's account has been closed

--- Additional comment from pmatilai on 2007-08-22 02:33:12 EDT ---

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

--- Additional comment from pmatilai on 2007-10-24 06:14:07 EDT ---

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

--- Additional comment from tao 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 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 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 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 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 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 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.