Bug#388489: Processed: Cloning this bug
Goswin von Brederlow a écrit :
Test multiarch:
% mkdir /usr/lib/i486-linux-gnu
% mv /usr/lib32/libz.* /usr/lib/i486-linux-gnu
Wrong. The purpose of multiarch is to remove bi-arch packages. With
multiarch if you want to install a 32-bit glibc on amd64, install the
package from i386. Not libc6-i386.
We can't lay an egg because we have no chicken and we can't breed a
chicken because we have no eggs. The purpose of libc6-i386 is to cover
the interim time till multiarch and it isn't to strictly deadlock
everything at bi-arch.
Well that's your opinion. It's not my opinion and also not the opinion
of Tollef for example (we discussed about how to implement multiarch
during Fosdem last year).
Remeber that we already did have the libc6 package from i386 in use in
ia32-libs (and still have). You wanted to have a special libc6-i386
package for amd64 and since you maintain glibc we respected that. We
can add libc6 back to the list of packages for amd64 if you don't want
to provide a transitional package that mimics multiarch. That would be
a one line change.
I am in favor of eventually dropping ia32-libs, because I consider this
package has not its place in main. You can't rebuild it from sources. I
has to go into testing.
The ld.so.conf.d/i486-linux-gnu.conf file is essential so multiarch
directories can be used already and to allow a smooth transition.
What do you mean by "smooth transition"? Could you explain to others
what do you have in mind, it seems you have your own view on how to
implement and how to do the transition to multiarch.
Until now the plan to transition to multiarch is the following:
- apply patch to binutils
- apply patch to gcc
- split-out binaries from libc6
all those steps could be done in parallel
- implement multiarch in dpkg.
Then you can install libc6:i386 on an amd64 system. No need to make an
other change, as libc6:i386 provide
The
ld.so.conf.d/i486-linux-gnu.conf files only logical place is in the
libc6[-i386] packages and the multiarch libc6 oni386 already has to
conflict with libc6-i386 on amd64 (reverse for libc6-amd64). If
ld.so.conf.d/i486-linux-gnu.conf is in any other package then that
just further complicates the dependencies and conflicts in the future.
Why do you want to add a conflict there? There is no need now. But if
you add the file, there will be a need to do that.
Why do you want for libc6-i386 servers as a "transition package" while
simply installing libc6:i386 will work?
I see 3 scenarios where I would consider this bug fixed:
1) you add the file
From my point of view this will complexify the transition to multiarch,
because you will need to add conflicts.
2) ia32-libs takes the libc6-i386 package
I already explained I am not in favor of that.
3) binutils adds the patch from #369064 and obsoletes the
/etc/ld.so.conf.d/arch-os-gnu.conf files
I don't see how it would fix the "problem". This patch only add the
native multiarch directory (ie i486-linux-gnu on i386, x86_64-linux-gnu
on amd64, etc...) to the search path. Not the 32- or 64-bit counterpart
one. Well I haven't looked in deep in your latest patch...
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
Reply to: