On Friday 25 April 2008 07:01:49 am Vincent Cojot wrote: > Here's what puzzles me: > > [EMAIL PROTECTED] ]# rpm -q libXpm > libXpm-3.5.5-3 #(is x86_64) > libXpm-3.5.5-3 #(is i386) > > [EMAIL PROTECTED] ]# rpm -ql libXpm|grep so > /usr/lib64/libXpm.so.4 > /usr/lib64/libXpm.so.4.11.0 > /usr/lib/libXpm.so.4 > /usr/lib/libXpm.so.4.11.0 > > [EMAIL PROTECTED] ]# ls -la /usr/lib64/libXpm.so > lrwxrwxrwx 1 root root 16 Apr 23 14:58 /usr/lib64/libXpm.so -> > libXpm.so.4.11.0 > > [EMAIL PROTECTED] ]# rpm -qf /usr/lib64/libXpm.so > libXpm-devel-3.5.5-3 > [EMAIL PROTECTED] ]# rpm -qf /usr/lib/libXpm.so > error: file /usr/lib/libXpm.so: No such file or directory > > The /usr/lib/libXpm.so symlink is missing from the i386 version of the RPM.
The unversioned .so symlinks are provided by the -devel packages, notice how neither libXpm lists a libXpm.so, they have libXpm.so.4 and libXpm.so.4.11.0. It looks like you have libXpm-devel.x86_64 installed, but not libXpm-devel.i386 installed. > Also, in this situation (flex example): > [EMAIL PROTECTED] ]# rpm -qf /usr/lib64/libfl.a > flex-2.5.4a-41.fc6 #(is x86_64) > [EMAIL PROTECTED] ]# rpm -q flex > flex-2.5.4a-41.fc6 > [EMAIL PROTECTED] ]# rpm -qf /usr/lib/libfl.a > error: file /usr/lib/libfl.a: No such file or directory > > If I need a 32bit/i386 libfl.a to compile 32bit progs on this x86_64 RHEL5, > might I be able to add flex-2.5.4a-41.fc6.i386.rpm from the i386 el5 > distribution media without causing side-effects to my x86_64 OS? As long as the package doesn't have any multilib file conflicts, no reason it should cause any other badness that I can think of. > Should this be evaluated on a case-by-case basis for every 'duplicate > needed rpm' because RH hasn't decided upon a standard on i386 vs x86_64 > packages on x86_64? > > I don't understand some of the design decisions here... If someone could > shed some light, Multilib is tricky. Some things don't make sense as multilib, while others definitely do, but are difficult to make multilib for assorted reasons (for example, packages can have overlap that requires retooling the packages). So a lot of things were automatically made multilib, because they had -devel sub-packages, and didn't introduce any conflicts, while other stuff has had to be addressed on a case-by-case basis. The criteria for what gets multilib treatment is still evolving. If you have a compelling reasons for why a package that isn't multilib should be, I'd say file a bugzilla. -- Jarod Wilson [EMAIL PROTECTED] _______________________________________________ rhelv5-list mailing list [email protected] https://www.redhat.com/mailman/listinfo/rhelv5-list
