Re: Debian Installer Stretch Alpha 8 release
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 <helmut@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
Reply to: