[Clc-crux64] blah32, blah64
First of all, hello to the list. 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. I have started using this technique on my system and suggest that future versions of crux64 do the same. Here is how I migrated to a 32bit chroot # Install all the packages # mkdir -p /usr/compat/crux32/var/lib/pkg/ touch /usr/compat/crux32/var/lib/pkg/db mount /cdrom cd /cdrom/crux (cd base; for pkg in *; do pkgadd -r /usr/compat/crux32 $p) (cd opt; for pkg in *; do pkgadd -r /usr/compat/crux32 $p) (cd contrib; for pkg in *; do pkgadd -r /usr/compat/crux32 $p) # Set up some mountpoints, in /etc/fstab. Mainly to reduce data replication # /usr/ports /usr/compat/crux32/usr/ports none auto,bind 0 0 /usr/pkgmk/source /usr/compat/crux32/usr/pkgmk/source auto,bind 0 0 /home /usr/compat/crux32/home none auto,bind 0 0 /usr/src /usr/compat/crux32/usr/src none auto,bind 0 0 You might also want to add devfs,proc and sysfs mount points too Copy anything else that the 32bit chroot might need such as the contents of /etc/ports and /etc/{passwd,shadow,group} , and make any required changes to the config files. Reboot or mount all the new mount points and test: $ chroot /usr/compat/crux32 firefox But of course we all knew how to do that didn't we ;P I'll probably make a port for this at some stage so then if one wants, as it's all about choice isn't it, 32bit compatability you can just do; $ prt-get depinst crux32 or something along those lines -- Lucas Hazel <lucas-antispam.2@digitillogic.net> Student, BSDfreak School of Maths and Computer Science University of New England Armidale, Australia [http://cs.une.edu.au] [http://www.digitillogic.net] ================================================= "Clothes make the man. Naked men are rarely taken seriously, or given employment." (Mark Twain) =================================================
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
participants (2)
-
Jeremy Jones -
Lucas Hazel