[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#914897: debootstrap, buster: Please disabled merged /usr by default



On Sat, Dec 01, 2018 at 07:20:57PM +0100, Didier 'OdyX' Raboud wrote:
> As a way to improve my understanding of the issue at hand, here's my current
> collection of data points regarding the "merged-/usr" question:
> 
> * "merged-/usr" was enabled by default in debootstrap on June 13. 2018, some 
>   5+ months ago. Any buster rootfs setup since has the /bin → /usr/bin 
>   symlink (and other caracteristics of merged-/usr).
> 
> 	https://tracker.debian.org/news/965045/accepted-debootstrap-10102-source-all-into-unstable/

For completeness sake you might want to start the story at the
point in pre-stretch-freeze era where the default was changed:

https://tracker.debian.org/news/807889/accepted-debootstrap-1085-source-into-unstable/

And then disabled and post-postponed to post-stretch release:
https://tracker.debian.org/news/815610/accepted-debootstrap-1087-source-all-into-unstable/




> 
> * With my TC hat on, I have formally asked the debootstrap maintainers
>   (and specifically Hideki Yamane) if they would consider a toggle of the
>   default.
> 
> 	https://bugs.debian.org/914897#73

May I ask you to share why you did that? I'm interested to know the
reasoning.

(It's not my understanding that this is how TC normally operates.)

> 
> * a discussion "usrmerge -- plan B?" was started on Nov. 20 on debian-
>   devel@l.d.o
> 
> 	https://lists.debian.org/20181120211617.gxnuwxpx2hy445ps@angband.pl
>   
>   It apparently follows #913229, #914204 and others.
> 
> * Currently, according to my `apt-file`, 259 binaries are shipped in /bin
>   directly, accross 85 packages. (for /sbin, 597 binaries for 190 packages).
> 
> * There exists a 'usrmerge' package since 2015, which transforms a rootfs with 
>   separate /{bin,sbin,lib} into a "merged-usr/" rootfs.  It has had 28 bugs 
>   over its lifetime; of which 4 are currently open.  After successful 
>   "installation" (when the postinst successfully ran the
>   /usr/lib/convert-usrmerge program), /{bin,sbin,lib} are made symlinks and 
>   the package can be removed.  The package doesn't include a way to revert the
>   rootfs to its previous state.
> 
> * Building source packages in a merged-/usr rootfs can make the resulting
>   binary packages broken in non-merged-/usr rootfs'es, because they'd be 
>   embedding references to /usr/bin/grep (e.g.), which don't exist in non-
>   merged-/usr rootfs'es. 

---> 
> To ensure this doesn't happen for packages built on 
>   Debian infrastructure, debootstrap has been updated to disable merged-/usr 
>   for the `buildd` variant (and buildd chroots have been rebuilt).

... while that change happened, I don't think that's what technically
disabled merged-usr on the debian buildd chroots. AIUI the buildd
chroots are created using debootstrap from stable-backports repository.
There was a new upload to stable-backports that enabled the merged-usr
by default which triggered a few problems. The admins thus explicitly
disabled merged-usr via the debootstrap commandline flag in the
continuous deployment system for buildd chroots and triggered chroot
recreation jobs.

> 
> * According to investigation done thanks to reproducible builds (which now
>   also varies the merged-/usr state of the build rootfs), and by others,
>   packages affected by this problem have begun receiving either 
>   reproducibility issue tags or Debian bugs:
> 
> 	https://tests.reproducible-builds.org/debian/issues/unstable/paths_vary_due_to_usrmerge_issue.html
> 	(currently: 59)
> 
> 	https://bugs.debian.org/cgi-bin/pkgreport.cgi?users=md@linux.it;tag=usrmerge
> 	(current total: 81; outstanding: 17)

FWIW I've analyzed all packages that are tagged on the reproducible
build page. Messing with the debian bts is just too time consuming as
if looking at this wasn't boring enough to begin with. If anyone thinks
there are some interesting data points to be found please ask.

> 
> I'll post my thoughts separately; please enhance or correct the above data
> as needed!
> 
> Cheers,
>     OdyX

Regards,
Andreas Henriksson


Reply to: