Control: clone 843073 -1 Control: reassign -1 debootstrap 1.0.85 Control: retitle -1 debootstrap: Please revert merged-/usr by default as it breaks builds Control: severity -1 serious Control: affects -1 dpkg-dev Control: severity 843073 wishlist Control: block 810499 by 843073 Control: severity 810499 serious Control: affects 810499 dpkg-dev
Hi! On Sun, 2016-11-13 at 08:38:53 +0100, Helmut Grohne wrote: > On Sat, Nov 12, 2016 at 08:55:43PM +0100, Michael Biebl wrote: > > Is this really so for all buildds? > > See #843433, the sparc64 buildds apparently do use a merged-usr chroot. > > The issue depends on the loader path of the architecture. Although I do > not understand why, it seems that /lib64 is less prone to exposing it > than /lib is. We have people saying: > * not reproducible on amd64 /lib64 (Marco) > * not reproducible on sparc64 /lib64 (Michael) > * reproducible on i386 /lib (#810499) > * reproducible on armhf /lib (Uwe) > > So the expectation I have is that it'll break: > * armel > * armhf > * i386 > * mips > * mipsel > * s390x > > Plus a number of non-release architectures. Thanks for taking a look! > > Hm, I would still consider it release critical, i.e. something which > > needs to be fixed before we can release stretch. Otherwise this will > > bite us later. > > I agree. Ok fine, this looks pretty worse than it looked before. So I'm rearranging the bugs to where they belong. > The /usr merge violates core assumptions in dpkg-shlibdeps. The reason > that amd64 isn't broken is sheer luck. > /etc/ld.so.conf.d/x86_64-linux-gnu.conf lists /lib before /usr/lib, so > dpkg-shlibdeps considers that first. Swapping them or simply removing > /lib (as seems reasonable on a merged /usr), breaks almost any build on > amd64 (e.g. dash). The breakage on amd64 is simply hidden. Right. I'm happy to assist people who want to fix this to try to find a proper solution in dpkg-dev, but I'm not planning on spending time on this on my own. On Sun, 2016-11-13 at 12:04:07 +0100, Marco d'Itri wrote: > On Nov 13, Helmut Grohne <hel...@subdivi.de> wrote: > > Thus I think that debootstrap should revert to unmerged /usr until > > dpkg-shlibdeps has been fixed. Fixing is non-trivial and likely requires > > an archive rebuild on several architectures. > Not really: dpkg-shlibdeps just needs to be fixed to search for > libraries in $directory and /usr/$directory, and then everything will > work again as usual. > And yes, hacks like this one are a side effect of maintaining support > for non-merged systems. Err, well exactly because usemerge is a major hack, and I'm actually surprised we are deploying systems by default with that. As an interesting thing to install and try out on ones system that's perfectly fine though. But IMO if the merge needs to be done it should be done by installing things into their final desired destination on each package. Of course that makes split installations not possible, but oh well. Thanks, Guillem
