[Clc-crux64] blah32, blah64

[Jeremy Jones]

Lucas Hazel Wrote

> First of all, hello to the list.

Hi!

> I just got me a shiny new amd64 3000+ so I put crux64 on it naturally.
> Overall it's a good effort, I just have some problems with 
> the structure in reguards to how 32bit compatability is handled.
> 
> The use of lib32/lib64 and port_name32 isn't really a good 
> idea IMHO, what I have now is a 32bit chroot which I use 
> whenever I find a peice of software that isn't amd64 ready, 
> this technique keeps the system cleaner I feel and already a 
> common practice on a number of systems, such as how linux 
> compatability is handled on *BSD systems.

32-bit vs 64-bit compatibility are different in kind, as far as I can
fathom, between {net/open/free}bsd and linux compatibility.  And, in fact,
the lib32/lib64 differentiation is how FHS semi-standards recommend we
separate architecture (as opposed to kernel/os) differences.  This
filesystem strucure (i.e. /lib32, /lib64, /usr/lib32, /usr/lib64) appeared
to me to be the fairly standard among other linux distributions ported to
64-bit architectures (including sparc64, hppa64, and x86_64).

As far as having a 32-bit chroot environment available to play with, or to
turn to in times of compilation trouble, I think that's a great idea, and
it's something I have on my own system already.  However, as far as me
including a ready-made 32-bit chroot environment, I don't see any pressing
need.  That environment is already provided by Per in vanilla crux.  I don't
think it's beyond anyone's capacity to download the vanilla crux iso image,
loop mount it, and install all the packages to, say, /home/joeuser/32.

Providing a limited set of 32-bit compatibility libraries was a way of
allowing some popular-but-not-open-source binaries to be run natively in a
64-bit environment (in particular, vmware), and to allow certain other
pieces of software (most notably, cvsup) to work in the 64-bit environment.
Is doubling the size of the distribution -- by providing a full 32-bit os
within the native 64-bit one -- a better solution?  I don't think so, not
when the option of installing vanilla crux within crux64 is always available
to anyone.

If I've misunderstood your arguments, I apologize (it's Saturday night,
after all, and I've been drinking Imperial Stout since around 3:00 this
afternoon...).  I've tried to strike a balance between simplicity (one of
the driving forces behind our appreciation of crux) and sticking to
standards.  And from what I've seen, the de facto standard for 64-bit
linuxes is to put native 64-bit libs in /lib64 and /usr/lib64, symlink /lib
and /usr/lib to those, and to put compatibility libs in /lib32 and
/usr/lib32.  Was there an argument as to why this was a bad idea?

Jeremy