ia32-libs

[Jerone Young]

On Mon, 2008-12-22 at 19:01 -0800, Steve Langasek wrote:
> 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.

True. I actually use skype for instance with this current method
(ia32-libs). Though there are some (mainly bigger apps) that you do have
to do chroot for with libs not in the ia32 libs package.

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

Thanks! That explains a lot! Seems like something to pursue though to
reach feature parity with the other major distros. I would think this is
something that Ubuntu Server folks would want more then desktop really,
as this would probably be a common case with many server apps (most the
closed source type). 

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

Yeap. Or maybe something like /lib/x86 ../lib/x86_64  whould also be a
good more cleaner convention. Only time will tell what things actually
end up looking like.

What is the best place to discuss this or find old discussions on this
subject? debian mailing list?

> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20081222/be351d7b/attachment.pgp