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:
You shouldn't have to use force -- yum install foo.i386 should just work
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.
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.
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.