On Sun, Aug 15, 2021 at 12:16:39AM +0100, Simon McVittie wrote: > On Sat, 14 Aug 2021 at 16:59:24 +0200, David Kalnischkies wrote: > > Wouldn't it be kinda strange to have the chroots building the packages > > for the first bookworm release using a layout which isn't supported by > > bookworm itself… > > Yes, it's a little strange, but that's what happens when we don't want > a mid-release-cycle flag day: we have to sequence things somehow. For best > robustness for users of non-merged-/usr, build chroots should likely > be one of the last things to become merged-/usr, and build chroots for > suites like buster and bullseye that support non-merged-/usr should stay > non-merged-/usr until those suites are completely discontinued. You snipped both times the [for me] logical consequence that all bookworm build chroots are kept in a [then unsupported] unmerged state as "one of the last things" aka until bookworm is discontinued, so that they are building the packages who do will encounter unmerged systems in the upgrade as a user can perfectly well upgrade from bullseye to the ninth point-release of bookworm months after the initial release of bookworm. > 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). So, your reasoning is that tooling will help us ensure that packages built on merged systems work on non-merged systems? Good! No flag day required then, we can just naturally upgrade all systems as they encounter the $magic and have new buildd chroots bootstrapped now merged instead of enforcing them being unmerged still (modulo whatever the implementation itself might be of course). I am happy as that wasn't clearly said before and current practice and previous discussions suggested the opposite¹ (at least for me). Thanks & good luck! If on the other hand you do still anticipate problems with packages built on merged systems for non-merged systems requiring a flag day I don't understand why it makes sense to have that flag day be bookworm release day² as that brings the anticipated problems to the bullseye→bookworm upgrades with the first point release (with the first package with a stable or security update to be more exact³). Best regards David Kalnischkies ¹ e.g. Marga is saying in #978636 msg#153 that migration from unmerged is not required to be implemented for bookworm [and therefore effectively at all] for unmerged to be unsupported in bookworm. ² Leaving aside how we would even technically implement a flag day so that unstable (building bookworm packages until release day) stays unmerged until magically merging on release day while testing merges on install (before that) for… testing? ³ I understand that only a subset actually breaks for non-merged if build on merged, but I prefer to assume that the first one is such a package to be prepared rather than pray to deity (pun intended) and hope for the best.
Attachment:
signature.asc
Description: PGP signature