Slashdot Mirror
Debian Votes on AMD64 in Sarge
JayBonci writes "According to a message sent to debian-vote, there is now a GR on the table as to whether or not to include AMD64 into the upcoming sarge release, even though it violates part of the LSB (Linux Standards Base). The debian-vote list has more discussion on it. Does this best meet the needs of the users?"
The solution that probably will be taken, after sarge, is multiarch; forget /usr/lib32 and /usr/lib64, think /usr/i486-linux/lib and /usr/x64_64-linux/lib. Solves the problem of both two and more (remember, the IA64 can both emulate IA32 and stuff like HPPA, for instance) architectures, but requires some work that most people probably won't let delay sarge.
/* Steinar */
(This comment is of course GPLed.)
I think the LSB says to put them in /lib64, which I find totally broken. Sure it allows for a 64-bit install to be built on top of an already existing 32-bit install.
/lib and the compatibility libs should have been moved to /lib32.
/lib. 32-bit legacy compatibility is just that -- legacy compatibility, and can fit in wherever. Maybe not even /lib32; perhaps demote it to /usr/lib32: no legacy binaries should be required to bring the system up, especially before /usr has been mounted.
I agree, it's hideous, for all the reasons you state. I'd go as far as saying that I don't think that "upgrading" an IA-32 installation to an AMD64 installation should even be supported. Backwards compatibility aside, they're separate architectures, and should thus require reinstallation. It's a small amount of short-term pain to avoid masses of legacy cruft building up afterwards.
What should have been done is on 64-bit distros which wish to offer 32-bit backward compatiblity, the default 64-bit libs should be in
Absolutely Right(tm). The 64-bit distro is in charge, so it gets dibs on
I'm also pleased that Debian has decided to call the architecture "amd64". "x86-64" looks and sounds ugly, IMHO.
-Stephen