On Thu, Feb 09, 2006 at 11:28:37PM +0100, Aurelien Jarno wrote: > > However, waiting some more will make it more difficult. I think this has > to be discuss widely. Maybe debian-devel ? >
Well I have discussed that on irc with Steve Langasek. Here is the log: The time is in CET format, so the first line has been written on Thu Feb 9 23:02 UTC 2006 aurel32 = me vorlon = Steve Langasek 00:02 < aurel32> I am currently looking at the patch to build an i386 libc on amd64 00:02 < liw> vorlon, mm, yeah, that requires direct access to a debian.org machine, so the statistics generation couldn't be done by an outsider 00:02 < vorlon> true 00:02 < vorlon> the only exported interface is the ldap one, AFAIK 00:02 < aurel32> I find the choice of /emul/ia32-linux a bit ugly 00:02 < aurel32> has this choice been discussed somewhere? 00:03 < pusling> tarzeau: are you the sidplay maintainer ? ;) 00:03 < tarzeau> pusling: why would i want to kick my own ass instead of just fixing the bug? 00:03 < vorlon> aurel32: I don't think /emul/ia32-linux is the FHS-endorsed path(?) 00:03 < vorlon> FHS/LSB 00:03 < aurel32> vorlon: for ia64 only 00:03 < aurel32> vorlon: for amd64 it is supposed to be /lib 00:03 -!- ruoso [EMAIL PROTECTED] has quit ["Leaving"] 00:04 < pusling> tarzeau: to make you get you self together ? ;) 00:04 < vorlon> right, so obviously we shouldn't be putting libc in /emul/ia32-linux on amd64... 00:04 < aurel32> vorlon: and /lib64 for the amd64 binaries 00:04 -!- CosmicRay [EMAIL PROTECTED]:452c:8843:1:20e:a6ff:fe66:c5a3] has quit ["Client exiting"] 00:04 < aurel32> the problem is that some packages started to use it 00:04 < vorlon> so slap them 00:04 < aurel32> actually it seems ia32-libs used /emul/ia32-linux originally on ia64 00:05 < aurel32> and somebody decided to use the same for amd64 00:05 < vorlon> yeah. Bad. 00:05 < aurel32> vorlon: that will probably break upgrade 00:05 < aurel32> also note that /emul/ia32-linux is hardcoded in the ia64 kernel 00:05 < vorlon> But we were talking about amd64, not ia64. :) 00:05 < aurel32> yes amd64 00:06 < aurel32> just to show it is silly to use the same path on amd64 00:06 < aurel32> another problem is that we can't use /lib as it is already the default path for the 64-bit libraries 00:07 < vorlon> the /emul/ crap should go away on amd64. I think we're actually going to have a hard time doing a fully FHS-compliant amd64 port, due to the requirement that 64-bit libs be stuffed in /lib64 instead of in /lib as on every other arch. 00:07 < aurel32> /lib64 being a symlink to /lib 00:07 < vorlon> but the interpreter can at least go in /lib where it's supposed to. 00:07 < vorlon> (since the names of the i386 and amd64 ELF interpreters don't conflict) 00:07 < aurel32> yes, this is already the case 00:08 < aurel32> well it is a symlink 00:08 < aurel32> maybe we could also use lib32? 00:08 < aurel32> that's not FHS compliant but better than the /emul crap 00:08 < aurel32> and that will probably be used for tri-arch on mips 00:09 < liw> ldapsearch -h bts2ldap.debian.net -p 10101 -x -b dc=bugs,dc=debian,dc=org 'debbugsID=340000' # that's supposed to be a valid query, right? 00:09 < doogie> newmaster has 8 penguins 00:09 < vorlon> I tend to agree with that. You probably need to still support /emul in the compiled-in linker path for the upgrade. 00:09 < vorlon> liw: it's a valid ldapsearch command with a valid ldap query. I don't remember what the ldap schema on there looks like. :) 00:10 < liw> hm, there was talk about aba moving and the service being temporarily out of order, but I thought that since the server now answers, it should now work 00:11 < doogie> dual cpu / dual core / hyperthread 00:11 < vorlon> yes, it should 00:11 < aurel32> vorlon: ok, so we just have to solve the fact than is /usr/lib32 is already a symlink to /emul/ia32-linux 00:11 < aurel32> vorlon: I will try to find a way to allow an upgrade with this setup So in short, we should use /lib32 and /usr/lib32 (nuking the symlink for the latter), but with still keeping /emul/ia32-linux in the search path. Then the package still using those paths should be transitioned. -- .''`. 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]
