On 2021-08-17, Holger Levsen wrote: > On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote: >> The failure mode we have sometimes seen is packages that were built in >> a merged-/usr chroot not working on a non-merged-/usr system, although >> that's detected by the reproducible-builds infrastructure and is already >> considered to be a bug since buster (AIUI it's considered a non-RC bug >> in buster and bullseye, as a result of things like #914897 mitigating it). > > FWIW i'm preparing a commit right now which will change the > reproducible-builds > infrastructure in so far as: > > - bullseye will not be tested anymore for differences of building with or > without the usrmerge package installed (just like stretch and buster were > and are not). > - bookworn and unstable will be tested for differences of building with or > without the usrmerge package installed.
Given: TC decision on "Merged /usr" https://bugs.debian.org/914897 The short of it, as I read it, is that non-usrmerge systems will be unsupported for bookworm, or did I misread that? I would almost think it makes more sense to *not* test usrmerge for bookworm, but continue to test it for bullseye and unstable (and experimental) in the reproducible builds infrastructure. This is my quick rationale for why I think that: * bullseye has been doing usrmerge variations for it's entire development cycle, it seems odd to change now. * Keeping unstable/sid with usrmerge variations is good for QA, as it does occasionally catch deeper issues. * Not doing usrmerge variations for bookworm is consistent with the plan for the next release (though we should have usrmerge always enabled then, as opposed to only building with non-usrmerge). It is also similar to build paths (which are not tested in the "testing" suite), a lower bar for the "testing" suite, as it is a relatively easy thing to workaround for reproducibility. But, I've only caught a small part of this thread, so maybe there's more to it. :) live well, vagrant
signature.asc
Description: PGP signature