Bug 460188
Summary: | multilib: Installing nss-mdns.x86_64 but not .i386 breaks name resolution for 32-bit programs | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Adam Goode <adam> |
Component: | rpm | Assignee: | Panu Matilainen <pmatilai> |
Status: | CLOSED DUPLICATE | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 11 | CC: | aflin, ffesti, jnovy, lpoetter, marcel, pmatilai, simberger, warren.crossing |
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-06-10 05:48:08 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
Adam Goode
2008-08-26 17:27:10 UTC
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 |