Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
On Mon, Feb 20, 2006 at 01:59:54AM +0100, Aurelien Jarno wrote: The amd64 port is currently providing 32-bit libraries via the ia32-libs package. This package was originally designed for ia64, and thus install 32-bit libraries in /emul/ia32-linux/ . This is not compliant with the FHS for amd64. Note also that this package does not rebuild the libraries, but use the ones in the i386 packages. FWIW, I do consider the nasty architecture special-casing required of us by the FHS to be a major reason why we should be trying to push forward with multiarch. There is no way to make an amd64 system comply with the current FHS without munging every single library package to install to a different path on amd64 than on all other architectures. I'm told that Red Hat is actually doing this, but I don't think it makes sense for us to go down that route... Since multiarch isn't solidifying very fast, though, it also doesn't make sense to hold up improving ia32-libs while waiting for it. If there's consensus that putting this stuff in /usr/lib32 on amd64 is prettier than /emul/ia32-linux, I see no reason not to move forward. Ultimately, though, it would be really really nice if multiarch happened, so that making a lib multiarch-safe only required adjusting the paths the package installs to, consistently across *all* architectures, and no more fiddling with package names and doing double-builds on each architecture and so on... Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: making udev require 2.6.15 kernels
Well, here I am, the unknowledgeable user who is stuck with a half-configured system and no upgrade path. I have kernel 2.6.10, but some program I was upgrading required a newer udev than 056, or whatever I have now. But, udev 084 (I believe that is the version) won't install because I am not running a kernel 2.6.12 or higher, and kernel-image 2.6.15 won't install because it requires a newer udev than I have. (Having packages.debian.org down doesn't help the situation, but that is a different matter.) In any case, I am unable to find any kernel images between 2.6.10 and 2.6.15 that I could try to install. Nor could I find any udev packages between the version in stable (056?) and unstable (084?). So, what can I do? I don't know what is only half-configured, but my flatbed scanner is now undetected. Please CC replies to me, since I am not subscribed to the list. If you need more information, please tell me which commands to run so I can supply you with more information. -kolibrie signature.asc Description: Digital signature
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote: If there's consensus that putting this stuff in /usr/lib32 on amd64 is prettier than /emul/ia32-linux, I see no reason not to move forward. My sense is that the concensus that exists is around FHS compliance. While I personally consider /usr/lib32 pretty ugly, I am sensitive to the fact that we have always tried to be FHS compliant in Debian. I'm willing to consider a cluefully constructed patch. Looking over the open bug reports, it's well past time for another general update of ia32-libs. I'll try to make time for it this week. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
On Mon, Feb 20, 2006 at 11:10:41AM -0700, Bdale Garbee wrote: On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote: If there's consensus that putting this stuff in /usr/lib32 on amd64 is prettier than /emul/ia32-linux, I see no reason not to move forward. My sense is that the concensus that exists is around FHS compliance. While I personally consider /usr/lib32 pretty ugly, I am sensitive to the fact that we have always tried to be FHS compliant in Debian. FHS actually has a libqual in it, where qual can be things like 32 or 64. For PPC64, s390x, sparc64 and AMD64 it says that 64 bit libraries should be put in /lib64 and 32 bit version in /lib. For IA64, it says 64 bit libraries should be put in /lib, but doesn't say where 32 bit versions belong. It says: IA-64 uses a different scheme, reflecting the deprecation of 32-bit binaries (and hence libraries) on that architecture. I think 32 bit it makes sense to actually put 32 bit libraries on ia64 in /lib32 too, instead of the current /emul/ia32-linux/, and think it would be more inline with the FHS. Is there a reason it's using /emul/ia32-linux/ ? So I would like both ia64 and amd64 to use /lib32. Looking over the open bug reports, it's well past time for another general update of ia32-libs. I'll try to make time for it this week. In the end, I'd like to get rid of ia32-libs, and have it be a dummy package. But on the other hand, I don't want to make a biarch version of things like the X libraries. PS: Does this really have to be on -release? Kurt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
Kurt Roeckx writes: In the end, I'd like to get rid of ia32-libs, and have it be a dummy package. But on the other hand, I don't want to make a biarch version of things like the X libraries. you can't get rid of it on ia64 unless you either drop the 32bit support or else you provide a cross-toolchain (ia64-x86). Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: making udev require 2.6.15 kernels
On Mon, Feb 20, 2006 at 09:21:18AM -0500, Nathan Gray wrote: Well, here I am, the unknowledgeable user who is stuck with a half-configured system and no upgrade path. I have kernel 2.6.10, but some program I was upgrading required a newer udev than 056, or whatever I have now. But, udev 084 (I believe that is the version) won't install because I am not running a kernel 2.6.12 or higher, and kernel-image 2.6.15 won't install because it requires a newer udev than I have. (Having packages.debian.org down doesn't help the situation, but that is a different matter.) In any case, I am unable to find any kernel images between 2.6.10 and 2.6.15 that I could try to install. Nor could I find any udev packages between the version in stable (056?) and unstable (084?). This is bug #349354. So, what can I do? Because you're upgrading from a 2.6.10 kernel, you can install yaird, which should satisfy the dependencies of the new 2.6.15 kernel package without requiring udev to be upgraded first. You can also force the upgrade of udev by touching /etc/udev/force-upgrade and calling dpkg --configure -a. This is not a discussion list. If you have any other questions, please follow up either to that bug report, or to debian-user. Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
Re: Moving 32-bit libraries to (/usr)/lib32 on amd64
On Mon, Feb 20, 2006 at 11:10:41AM -0700, Bdale Garbee wrote: On Mon, 2006-02-20 at 02:23 -0800, Steve Langasek wrote: If there's consensus that putting this stuff in /usr/lib32 on amd64 is prettier than /emul/ia32-linux, I see no reason not to move forward. My sense is that the concensus that exists is around FHS compliance. While I personally consider /usr/lib32 pretty ugly, I am sensitive to the fact that we have always tried to be FHS compliant in Debian. /lib64 and /lib32 : 64/32-bit libraries (architecture dependent) The 64-bit architectures PPC64, s390x, sparc64 and AMD64 must place 64-bit libraries in /lib64, and 32-bit (or 31-bit on s390) libraries in /lib. The 64-bit architecture IA64 must place 64-bit libraries in /lib. http://www.pathname.com/fhs/pub/fhs-2.3.html#LIB64 So there really is no way to comply with the current FHS on amd64 without some serious package special-casing. That makes /emul/ia32-linux vs. /usr/lib32 entirely a question of aesthetics, not standards-compliance. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. [EMAIL PROTECTED] http://www.debian.org/ signature.asc Description: Digital signature
