On Mon, 10 Oct 2022 at 13:24:57 +0100, Luca Boccassi wrote: > On Mon, 10 Oct 2022 at 13:15, Holger Levsen <hol...@layer-acht.org> wrote: > > do we really want that? I understand this is supposed to be(come) > > an unsupported configuration? > > At least for the remainder of the Bookworm development cycle, > definitely yes. After Bookworm is released we can re-evaluate.
With TC-member hat on: for at least bookworm, sid and experimental, yes we would like reproducible-builds to test the non-merged-/usr configuration (which will become unsupported) in one build, and the merged-/usr configuration (which will become mandatory) in the other. This is so that if a package is misbuilt in a merged-/usr chroot (or in theory if it's misbuilt in a non-merged-/usr chroot), it will show up as a non-reproducibility. This lets us be more confident that building packages in a non-merged-/usr chroot (currently being done on the official buildds) and building packages in a merged-/usr chroot (what we should do in future) are both valid things to do and will not break too many packages. The most common failure mode is that if you build a package in a merged-/usr chroot, that sometimes results in the binary package hard-coding paths that are valid with merged-/usr but invalid for non-merged-/usr, such as /usr/bin/sh and /bin/perl. When everyone has merged-/usr systems, this failure mode will become a non-issue and we can stop testing for it, but we cannot assume that everyone running testing/unstable has merged-/usr systems until after bookworm has been released. This is because the dist-upgrade from bullseye to bookworm is done in an arbitrary order, so (almost) any package might get upgraded before the new init-system-helpers pulls in usrmerge. See <https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=994388#110> for more details. For trixie, and for unstable and experimental starting from the end of the bookworm freeze, reproducible-builds should use merged-/usr for both builds. Thanks, smcv
