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