Bug 176174 - rpm -Fvh ignores the architecture when choosing RPMs to freshen
rpm -Fvh ignores the architecture when choosing RPMs to freshen
Status: CLOSED DUPLICATE of bug 171743
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: rpm (Show other bugs)
4.0
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Paul Nasrat
Mike McLean
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-19 15:21 EST by John Caruso
Modified: 2009-01-05 23:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-21 17:28:54 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-12-19 15:21:44 EST
Background:
This bug was formerly opened by me (as bug 171743) but was then closed as a
duplicate of an enhancement request.  I'm reopening it because 1) it applies to
RHEL4, not RH9, 2) it's not an exact duplicate of the enhancement request, and
3) most importantly, I consider it to be a high priority bug, NOT an enhancement
request (as I said in the bug text: "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").  The
enhancement request has simply been ignored for two and a half years and it
seems clear that it will continue to be ignored in the same way, so marking bug
171743 as a duplicate of it was tantamount to saying that it would never be
fixed, and IMO a bug this serious shouldn't be fobbed off in that way.

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 2 Jeff Johnson 2006-01-06 11:36:39 EST

*** This bug has been marked as a duplicate of 88623 ***
Comment 3 Ernie Petrides 2006-03-21 17:28:54 EST
Reclosing as a dup of John's original bug against RHEL4.

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

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