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. > 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. 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. 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. The problem has been known for some 8 months and hasn't been fixed. Helmut
