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