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.gxnuwxpx2hy44...@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=m...@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
