Bug 52878 - -Fvh does not discriminating between i386 and i686
-Fvh does not discriminating between i386 and i686
Status: CLOSED WONTFIX
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-08-30 08:59 EDT by Gene Czarcinski
Modified: 2007-04-18 12:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-08-30 09:00:01 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 Gene Czarcinski 2001-08-30 08:59:57 EDT
Description of Problem:
Downloaded new glibc version and attempted to "freshing" with:

rpm -Fvh glibc-*

failed because of conflicts bettween glibc-...i386.rpm and glibc-...i686.rpm

Version-Release number of selected component (if applicable):


How Reproducible:
everytime

Steps to Reproduce:
1. see above
2. 
3. 

Actual Results:
freshen failed ... I had to select inividual files to freshen

Expected Results:

Since i686 was installed, that would have been selected and the i386
package ignored
Additional Information:

This may be one of those "working as designed" in which case I will
resubmit as an RFE.
Comment 1 Jeff Johnson 2001-08-30 09:27:22 EDT
rpm has no way to tell what the intent is when given multiple packages
that differ only in arch, either of which would "work", on the
command line. While an affinity scheme with the arch of the
old package could be worked out, that doesn't exactly handle the case of
	cpu		athlon
	installed		glibc-*.i586
	upgrade choices	glibc-*.i386 glibc-*.i686
even if the existing platform scoring mechanism within rpm, usually used
as an affinty metric between a new package and the cpu  were to be
generalized to check the old (but there can be several, for example, kernel,
packages installed, with different arch's!) package as well.

Any deterministic policy mechanism for choosing packages is bound to
miss the intent somehow/somewhen.

What needs doing IMHO is finer grained dependencies to track explicit
functionality, arch is far too slippery for a reliable choice. That will happen
eventually, but, for now, make your own choice clear on the rpm command
line.


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