Description of problem: If the x86_64 version of nss-mdns is installed without the i386 version, 32-bit programs cannot resolve hosts. Version-Release number of selected component (if applicable): nss-mdns-0.10-4.fc9 How reproducible: Always. Steps to Reproduce: 1. yum remove nss-mdns 2. yum install nss-mdns.x86_64 3. wine firefox.exe (for example) Actual results: No DNS resolution. Expected results: DNS resolution. Additional info: Either glibc must not fail if nsswitch.conf is invalid, or it should have some way of having a 64-bit and 32-bit override file. (Maybe nsswitch.d is needed?) Or, nss-mdns.x86_64 should Depend on nss-mdns.i386 when that feature is allowed in RPM. (But can nss-mdns.x86_64 Depend on nss-mdns.i386 ONLY when 32-bit glibc is installed? Otherwise 64-bit only users would be out of luck.)
Similar result in Fedora 10 x86_64. Java, javaws and firefox all failed to resolve names until nss.mdns.i386 was installed. No mention of dependencies when installing rpms or using yum.
Ok, after a few discussions we came to the conclusion that multilib is broken in this respect. The only possible fix would be to add a dependency on the 32bit version of nss-mdns in the 64bit RPM. That would upset a lot of people. So we won't do it. RPM doesn't allow 'conditional' dependencies. While I think it is unlikely that this will ever be added I am now reassigning this to rpm. Maybe the rpm guys know a way how to fix this issue?
*** Bug 431659 has been marked as a duplicate of this bug. ***
libasound actally exposes the same problem: the 64bit libasound-plugins-pulse installs a config file fragment that breaks 32bit libasound unless also the 32bit libasound-plugins-pulse is installed. I have hence marked bug 431659 as duplicate of this issue. multilib is our downfall.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** This bug has been marked as a duplicate of bug 442047 ***
This happened to me the other way round: the i586 version was installed because of some dependencies and silently broke 64 bit applications. Wouldn't it be an option to add dependencies for the x86_64 version when it is installed on a 64 bit system? (or is that also impossible with rpm)
The system looks for libraries according to LD_LIBRARY_PATH or /etc/ld.conf and is updated with ldconfig. A good debugging step here is to run locate, strace and file look for where the system is getting libasound.so from >strace aplay my.wav open("/usr/lib/libasound.so.2", O_RDONLY) = 3 >locate libasound.so /usr/lib32/libasound.so.2 /usr/lib32/libasound.so.2.0.0 /usr/lib/libasound.so.2 /usr/lib/libasound.so.2.0.0 /usr/lib/x86_64-linux-gnu/libasound.so.2 /usr/lib/x86_64-linux-gnu/libasound.so.2.0.0 file /usr/lib/libasound.so.2.0.0 /usr/lib/libasound.so.2.0.0: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=0x9b9b9d237e06016fa10b020c5ddfa6cf494ad9c3, stripped I moved /usr/lib/libasound.so.* /old and then the system can find the correctly linked version of the file. You guys need to be posting the output of these commands in general. So we can work out what is what. NO VOODO