Bug 474934

Summary: cant install any 32bit libs for app compatibility without rpm --force. Breaks system updates.
Product: [Fedora] Fedora Reporter: Dave Booth <limey.dave>
Component: yumAssignee: Seth Vidal <skvidal>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 10CC: ffesti, james.antill, katzj, pmatilai, tim.lauridsen
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2009-01-21 19:07:57 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Dave Booth 2008-12-05 22:14:34 UTC
Description of problem:

No 32bit compatibility libs installed by any packages on x86_64 media. Attempting to add these from any repo fails since the 32bit and 64bit rpms differ only in that one installs the 32bit library in */lib/.... and the other installs the 64bit library in */lib64/.... Every other file conflicts and so the package must be installed with rpm --force

This also breaks attempts to update the system after forcing the second package on there.

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


How reproducible:


Steps to Reproduce:
1. Install from x86_64 media
2. Attempt to install a 32bit lib to support a 32bit app.
3.
  
Actual results:
packages conflict, rpms must be installed with rpm --force, breaks yum updates, breaks "add/remove software" from desktop.

Expected results:
Either the 64bit rpm should include 32bit libs for backwards compatibility or both should be repackaged so they do not conflict.

Additional info:

Comment 1 Jeremy Katz 2008-12-05 22:20:30 UTC
You shouldn't have to use force -- yum install foo.i386 should just work

Comment 2 seth vidal 2008-12-05 22:32:03 UTC
if you're installing  i386 pkgs matching the x86_64 pkgs in a separate transaction won't that cause problems for rpm laying down the files?

I know that one order or the other used to cause problems - you had to install them in the same transaction before.

Comment 3 Dave Booth 2008-12-05 22:49:28 UTC
it does cause problems. /usr/lib/libfoo doesnt conflict with /usr/lib64/libfoo, but /usr/share/foo/* are in both rpms. 

its a beast of an issue because once you find an app that needs an additional 32bit lib you have to run yum to get it, let yum resolve the dependencies and download the one you want and everything it needs then fail on the conflict, then go trawling through the yum cache doing rpm --force.

If there were a lot of deps its even worse, because you've got to either do the forced installs in the correct order or use --nodeps and risk missing one or two.

Comment 4 seth vidal 2009-01-21 19:07:57 UTC
I don't believe there's anything to be done here. The ordering of when the pkgs get installed does still matter. But this isn't exactly a bug. It's more like a known feature.