ia32-libs

Steve Langasek steve.langasek at ubuntu.com
Tue Dec 23 03:01:38 GMT 2008


On Mon, Dec 22, 2008 at 02:27:05PM -0600, Jerone Young wrote:
> > > 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? 

> Because the binary libaries need to be split into different directories.
> The reason users have to create an entire chroot enviroment to a 32bit
> app on Ubuntu/Debian 64-bit is because of this very thing. While other
> distros you don't have to do this since there is a clear split on the
> binary library directories.

Well, no.

a) There are a variety of 32-bit apps that you don't need to create a chroot
environment for on Debian or Ubuntu, because the most important shared
libraries are packaged as 32-bit variants for the amd64 architecture.  We
simply have the paths reversed to optimize for the common case, namely that
amd64 libs are in /usr/lib when using the amd64 port and i386 libs are in
/usr/lib32.

b) The reasons that prevent this from being easily generalizable - the lack
of package toolchain support for cross-installation of packages leading to a
requirement to special-case these builds in the source package - apply with
either the Debian or the Red Hat style.  In the case of RPM distros, they're
ahead simply because they've been willing to accept a "good enough" design
in their package management for this, whereas that idea hasn't gotten a lot
of momentum in Debian/Ubuntu circles because the expedient solutions are
also not very good designs overall.  And the elegant solutions don't have
momentum because... <shrug>

> > 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.

> So
> maybe /lib_x86_64 , /lib_x86,/lib_PPC32, /lib_PPC64, /lib_IA64, /lib_IA32 would also be a better convention? Perhaps just having /lib is dated since was normally not the case of having different binary libraries till current times.

This approximates multiarch, FWIW.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org



More information about the ubuntu-devel mailing list