Aurelien Jarno <[EMAIL PROTECTED]> writes: > Goswin von Brederlow a écrit : > 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.
My plan is to provide an environment where packages can already switch to multiarch and can be used as is (see fakeroot below) or with the help of a simple apt/dpkg-deb wrapper even though some slow moving packages like glibc neccessarily are behind on converting. Making libc6-i386 behave just like libc6:i386 means that we don't have to stop everything till glibc is converted. > Until now the plan to transition to multiarch is the following: > - apply patch to binutils > - apply patch to gcc The multiarch includes are already searched by gcc. When I move /usr/lib32/libc.{a,so} to /usr/lib/i486-linux-gnu and patch binutils then gcc -m32 works just fine. Without binutils patch it says "/usr/bin/ld: cannot find -lc". Doesn't even need a gcc recompile. What patch is missing? > - split-out binaries from libc6 and move libnss* and gconv to multiarch dirs. > all those steps could be done in parallel > > - implement multiarch in dpkg. That can be done in parallel too. And it can be tested with simple libs like zlib without the need to have glibc fully ready. > Then you can install libc6:i386 on an amd64 system. No need to make an > other change, as libc6:i386 provide Every other library can also be changed to multiarch in parallel. Provided ld looks there. A prime candidate for this is fakeroot which comes with libs for multiple archs. Since nothing gets compiled against those libs the binutils bug doesn't matter there. The ideal package to test and use the runtime stuff for multiarch. It only needs support from the ld, meaning libc6-i386 on amd64. >> 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. Both libc6:i386 and libc6-i386 provide the ld. Without proper conflicts, replaces, provides you get an overwrite error. So I don't add a conflict where there isn't already is one. > Why do you want for libc6-i386 servers as a "transition package" while > simply installing libc6:i386 will work? Because we don't have a (usable) libc6:i386 in the archive yet and with the goal of multiarch it is not there to stay. So it is temporary, transitional. That's just what it is. The current libc6:i386 does not look in the multiarch dirs for its plugins so it can not be converted by the apt/dpkg-deb wrapper automatically. It needs to be patched and recompiled for that. Most other packages can be converted on the fly. The closer libc6-i386 mimics a multiarch libc6:i386 the better people can test multiarch with the wrapper or convert their own libs. >> 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. The ld already neccessitates the conflict so no change there. >> 2) ia32-libs takes the libc6-i386 package > > I already explained I am not in favor of that. And I prefer it that way too as long as it doesn't hinder me. >> 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... Please read that bug again. It adds the native multiarch dir to every output format. The native dir for that format. Elf 32bit i486 gets i486-linux-gnu as dir. Elf 64bit amd64 gets x86_64-linux-gnu as dir. Exactly as we want it. It is easy to miss because binutils still uses i386 so /usr/lib/i386-linux-gnu is used. The second patch corrects that too. In fact this is better than ld.so.conf.d since only linking 32bit code would look in i486-linux-gnu and only 64bit code in x86_64-linux-gnu. No '/usr/bin/ld: skipping incompatible /usr/lib/x86_64-linux-gnu/libc.so when searching for -lc' warnings. MfG Goswin