On Friday 25 April 2008 07:01:49 am Vincent Cojot wrote:
> Here's what puzzles me:
>
> [root@(protected)
> libXpm-3.5.5-3 #(is x86_64)
> libXpm-3.5.5-3 #(is i386)
>
> [root@(protected)
> /usr/lib64/libXpm.so.4
> /usr/lib64/libXpm.so.4.11.0
> /usr/lib/libXpm.so.4
> /usr/lib/libXpm.so.4.11.0
>
> [root@(protected)
> lrwxrwxrwx 1 root root 16 Apr 23 14:58 /usr/lib64/libXpm.so ->
> libXpm.so.4.11.0
>
> [root@(protected)
> libXpm-devel-3.5.5-3
> [root@(protected)
> 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):
> [root@(protected)
> flex-2.5.4a-41.fc6 #(is x86_64)
> [root@(protected)
> flex-2.5.4a-41.fc6
> [root@(protected)
> 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
jwilson@(protected)

_______________________________________________
rhelv5-list mailing list
rhelv5-list@(protected)
https://www.redhat.com/mailman/listinfo/rhelv5-list