Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
On Sat, Feb 25, 2006 at 07:55:00AM +0100, Christian Perrier wrote: OK, sorry for the confusion but I really didn't want to see Aurélien just stop this work which I'm pretty sure he's doing well. For dpkg, I think I've seen some discussion but Guillem Jover and/or Frank Lichtenheld have probably a better picture. Anyway, the dpkg development model is now pretty much opened so anyone with ideas/skills/patches can probably come up and discuss in debian-dpkg... The first part is not quite true yet; currently I have no real idea of the needed/proposed changes to dpkg for multiarch. The second part however is true: I will happily work with anyone who proposes multi-arch patches for dpkg to test, discuss and integrate them... (General remark without reference to any special incident: please use the BTS for patches, do not post them directly to the list) Gruesse, -- Frank Lichtenheld [EMAIL PROTECTED] www: http://www.djpig.de/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
Hi! Some update on this, as we have evolved a lot since the last mail. Bdale Garbee a écrit : On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote: Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port compliant with the FHS, which is almost impossible given the current setup, ie 64-bit libraries in /lib. However, it would make it compliant with the part of the FHS which says that alternative libraries have to be in (/usr)/libqual. And it would make us compatible with other distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32. What sort of value should we assign to achieving that level of compatibility with other distributions before multiarch, where I expect us to be in the lead and others to be trying to figure out if/how to be compatible with Debian? Part of the reason I'm unhappy about the current FHS situation is that qual seems generally to get defined as 32 or 64 and the definition of what belongs in the unqualified version of the directories feels inconsistent across architectures. Part of what I like about our multiarch strategy is generalizing this to handle more interesting cases like emulated execution environments, etc. The world just isn't as simple as 32 vs 64 implies... I'm inclined to make as few structural changes to ia32-libs as possible pending multiarch implementation. The reason is that anything we change is going to make work for people, including work we can't anticipate or judge the scale of, like users who have laboriously worked to manually install additional libraries on their systems. If we're going to put people through a transition process, I'd prefer it be the transition to multiarch! You have been heard! The glibc currently in incoming has a preliminary multiarch support. It currently looks to librairies in both (/usr)/lib and (/usr)/lib/$(host-triplet)/. It support additional libraries (like the current one in multilib), via ldconfig, with /lib/ldconfig/ being the configuration directory. Using this it will be possible to add a link from (/usr)/lib64 to the multiarch directories to be compliant with the FHS. And that let time to discuss if we want a (/usr)/lib32 or not on amd64 :). Currently those directories are supported on all architectures, but only amd64 has files in them, a libc6 for i386. It will be used as a test architecture before doing the same on other 32/64 bit architectures, as there are very few packages to changes. The next step is to add support to gcc, and to move all 32-bit libraries on amd64 to (/usr)/lib/i486-linux-gnu. I will send you some update and some patches for gcc, zlib (needed for gcc) and ia32-libs soon. Bye, Aurelien -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
On Thu, Feb 23, 2006 at 10:58:15PM +0100, Aurelien Jarno wrote: Some update on this, as we have evolved a lot since the last mail. Bdale Garbee a écrit : On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote: Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port compliant with the FHS, which is almost impossible given the current setup, ie 64-bit libraries in /lib. However, it would make it compliant with the part of the FHS which says that alternative libraries have to be in (/usr)/libqual. And it would make us compatible with other distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32. What sort of value should we assign to achieving that level of compatibility with other distributions before multiarch, where I expect us to be in the lead and others to be trying to figure out if/how to be compatible with Debian? Part of the reason I'm unhappy about the current FHS situation is that qual seems generally to get defined as 32 or 64 and the definition of what belongs in the unqualified version of the directories feels inconsistent across architectures. Part of what I like about our multiarch strategy is generalizing this to handle more interesting cases like emulated execution environments, etc. The world just isn't as simple as 32 vs 64 implies... I'm inclined to make as few structural changes to ia32-libs as possible pending multiarch implementation. The reason is that anything we change is going to make work for people, including work we can't anticipate or judge the scale of, like users who have laboriously worked to manually install additional libraries on their systems. If we're going to put people through a transition process, I'd prefer it be the transition to multiarch! You have been heard! The glibc currently in incoming has a preliminary multiarch support. It currently looks to librairies in both (/usr)/lib and (/usr)/lib/$(host-triplet)/. It support additional libraries (like the current one in multilib), via ldconfig, with /lib/ldconfig/ being the configuration directory. Using this it will be possible to add a link from (/usr)/lib64 to the multiarch directories to be compliant with the FHS. And that let time to discuss if we want a (/usr)/lib32 or not on amd64 :). Currently those directories are supported on all architectures, but only amd64 has files in them, a libc6 for i386. It will be used as a test architecture before doing the same on other 32/64 bit architectures, as there are very few packages to changes. I'm concerned that putting files in /usr/lib/i486-linux-gnu/ may be premature. Has thought been given to what this means for the upgrade path when (...if) dpkg is extended to support installing Arch: i386 multiarch debs directly on amd64? I suppose it should just be a Replaces:, but it still seems like it will be an extra unnecessary transition. -- 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: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
Steve Langasek a écrit : On Thu, Feb 23, 2006 at 10:58:15PM +0100, Aurelien Jarno wrote: Some update on this, as we have evolved a lot since the last mail. Bdale Garbee a écrit : On Tue, 2006-02-21 at 07:10 +0100, Aurelien Jarno wrote: Moving 32-bit libraries to (/usr)/lib32 won't make the amd64 port compliant with the FHS, which is almost impossible given the current setup, ie 64-bit libraries in /lib. However, it would make it compliant with the part of the FHS which says that alternative libraries have to be in (/usr)/libqual. And it would make us compatible with other distributions like Gentoo or Ubuntu that have choosen to use (/usr)/lib32. What sort of value should we assign to achieving that level of compatibility with other distributions before multiarch, where I expect us to be in the lead and others to be trying to figure out if/how to be compatible with Debian? Part of the reason I'm unhappy about the current FHS situation is that qual seems generally to get defined as 32 or 64 and the definition of what belongs in the unqualified version of the directories feels inconsistent across architectures. Part of what I like about our multiarch strategy is generalizing this to handle more interesting cases like emulated execution environments, etc. The world just isn't as simple as 32 vs 64 implies... I'm inclined to make as few structural changes to ia32-libs as possible pending multiarch implementation. The reason is that anything we change is going to make work for people, including work we can't anticipate or judge the scale of, like users who have laboriously worked to manually install additional libraries on their systems. If we're going to put people through a transition process, I'd prefer it be the transition to multiarch! You have been heard! The glibc currently in incoming has a preliminary multiarch support. It currently looks to librairies in both (/usr)/lib and (/usr)/lib/$(host-triplet)/. It support additional libraries (like the current one in multilib), via ldconfig, with /lib/ldconfig/ being the configuration directory. Using this it will be possible to add a link from (/usr)/lib64 to the multiarch directories to be compliant with the FHS. And that let time to discuss if we want a (/usr)/lib32 or not on amd64 :). Currently those directories are supported on all architectures, but only amd64 has files in them, a libc6 for i386. It will be used as a test architecture before doing the same on other 32/64 bit architectures, as there are very few packages to changes. I'm concerned that putting files in /usr/lib/i486-linux-gnu/ may be premature. Has thought been given to what this means for the upgrade path when (...if) dpkg is extended to support installing Arch: i386 multiarch debs directly on amd64? I suppose it should just be a Replaces:, but it still seems like it will be an extra unnecessary transition. After a discussion on IRC, it seems there is no consensus about how multiarch should be done. Therefore I stop working on that (patches are still welcome for glibc). The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian GNU/Linux developer | Electrical Engineer `. `' [EMAIL PROTECTED] | [EMAIL PROTECTED] `-people.debian.org/~aurel32 | www.aurel32.net -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. Bdale -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
Bdale Garbee writes: On Fri, 2006-02-24 at 01:12 +0100, Aurelien Jarno wrote: The only change planned is to make libc6-dev-i386 and libc6-i386 provide a glibc on amd64 instead of ia32-libs. It will be in /emul/ia32-linux (I still have to find how to do that cleanly in the debhelper files). Bdale, do you agree with such a change? Yes, I think we can handle that. It means some small work on ia32-libs to stop delivering any conflicting files, but I'm sure we can work that out easily enough. If you want to provide me a patch for ia32-libs that does what you want it to do, that would be welcome. thanks. with this setup we are able to build our toolchain without build dependencies on ia32-libs or with packages conflicting with future multiarch packages (maybe additionally building lib32z1 from zlib). Will ia32-libs on ia64 still be supported for the etch release? Matthias -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Multiarch support (was Moving 32-bit libraries to (/usr)/lib32 on amd64)
After a discussion on IRC, it seems there is no consensus about how multiarch should be done. Therefore I stop working on that (patches are still welcome for glibc). Is this really the best thing to do? Even though there is no consensus (I overread the thread and anyway most parts of it fly in the stratosphere from my point of view), I'm not sure that abandoning the work is really the answer in this situation. OK, more talk is needed, maybe use a good BOFH at Debconf is worth it because controversial issues are better being talked in live discussions, but I think that the probably good work you did here should not be left as is. I'm maybe over-explaining but it seems that you're a little upset here (correct me if I'm wrong...but IRC excerpts I've seen on #d-d-fr make me think it)and you're maybe overreacting (no offence intended: you know me and you know how I respect your work). In short, please keep up the good work, the discussions and the like. Debian needs such melting pot of ideas. This will not be the last time that people won't agree with your ideas or proposals anyway..:=) /end of bubulle philosophical thoughts. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
