Bug#274367: glibc: [amd64] New GLIBC pass to create 32bit libc6-i386 and libc6-dev-i386 packages
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 [n=ruoso@201.29.209.228] 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 [n=jgoerzen@2002: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
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: