ia32-libs

[Kjeldgaard Morten]

On 22/12/2008, at 17.15, Jerone Young wrote:

> On Mon, 2008-12-22 at 09:32 +0100, Kjeldgaard Morten wrote:
>> On 22/12/2008, at 04.44, Jerone Young wrote:
>>
>>> You can easily run & install 32bit apps on these distros because the
>>> 32-bit libs are placed in /lib & /usr/lib .. while the 64bit libs  
>>> are
>>> placed in /lib64 & /usr/lib64. This allows their 64bit distros to  
>>> have
>>> easy 32bit comparability and easily install 32bit packages on top of
>>> the
>>> 64bit distro.
>>
>> ... and is the cause of the horrible, horrible breakages. One of the
>> reasons we left the RHEL distro.
>
> Can you explain? I have yet to see any breakage using this method.  
> This
> appears to be a much better method as libraries are easily seperated  
> and
> installable over time.

First of all, /usr/lib64 and /lib64 are awful kludges. The _logical_  
place to put  libraries  is /usr/lib and /lib, no matter what hardware  
the system is running on. Why should the filesystem vary with CPU  
architechture? For some strange reason, FSSTD introduced that awful / 
lib<qual> and /usr/lib<qual> convention for 64 bit support, with the  
exception of IA64 which goes in /usr/lib. One can guess that this  
ended up in the standard due to pressure from RedHat.

Adopting /usr/lib64 will mean that packages for amd64l needs to be  
configured differently from every other platform... a packaging and  
debugging nightmare.

In practice, RPM packagers can't figure out to create packages that do  
this consistently, which means that 64 bit libraries end up in /usr/ 
lib and sometimes 32 bit stuff ends up in /usr/lib64. Often, only one  
version or the other is available. This is especially a problem since  
RHEL only includes a small subset of packages, so you are forced to  
use 3rd party repos of quite varying quality.

In a few years, the deprecation of 32-bit binaries (and hence  
libraries) will be completed, and so the problem and the 32-specific  
applications will disappear.

Cheers,
Morten