mortenkjeldgaard at gmail.com
Mon Dec 22 18:58:30 GMT 2008
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
>>> placed in /lib64 & /usr/lib64. This allows their 64bit distros to
>>> easy 32bit comparability and easily install 32bit packages on top of
>>> 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.
> appears to be a much better method as libraries are easily seperated
> 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
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.
More information about the ubuntu-devel