On Sun, 15 Aug 2021 at 11:52:21 +0200, David Kalnischkies wrote: > 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.
Hmm, that's a good point. That hadn't occurred to me, and you're right, it's not ideal. One way out of this would be to say that it is a RC bug for packages in bookworm to have different contents when built in equivalent merged-/usr and unmerged-/usr chroots/containers (a higher severity than is currently applied, which I think would be a "normal" or "minor" bug for violating the Policy "should" rule that packages should be reproducible). That would mean we can validly merge /usr in buildd chroots, and if any package ends up broken in that situation, it's up to the package maintainer (or our usual NMU/bug-squashing processes) to fix it. According to https://isdebianreproducibleyet.com/, fewer than 5% of Debian packages are non-reproducible for any of the reasons we test, including but not limited to whether the buildd chroot was merged-/usr (the reproducible-builds infrastructure uses unmerged-/usr for "build 1" and then installs usrmerge before "build 2"), so that's an upper bound for the number of packages affected. Another way out of this would be to say that merged /usr is the only state supported for bookworm, with the exception that chroots/containers that will never be upgraded beyond bookworm (+ updates + security) are allowed to remain unmerged-/usr (and we'd probably want to say that adding bookworm-backports to an unmerged-/usr chroot/container is officially not supported either). That would mean the unmerged buildd chroots are (just about) in a supported state, while still letting maintainers assume/require merged-/usr post-bookworm, because by definition the chroots/containers where that exception applies are never going to reach a post-bookworm state (they'll be discarded when they are no longer used, instead). > So, your reasoning is that tooling will help us ensure that packages > built on merged systems work on non-merged systems? Good! This is basically another phrasing of the first option I described above, I think. > 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). If we are going to reach a state where package maintainers can assume/require merged-/usr (for example being able to drop code paths that only needed to exist because unmerged-/usr is supported), then we need some point in the release/upgrade process where that requirement becomes official - and IMO that point in time might as well be a particular Debian release, because that would be consistent with the rules we normally use to drop other code that was historically required but is no longer relevant, like Breaks/Replaces or workarounds in maintainer scripts. It isn't a flag day in the sense that the whole world needs to switch at the same time, more like a support cutoff (like the way we discontinue security support as a stable suite gets older, first for selected problematic packages and architectures and then for the entire suite). That point doesn't necessarily have to be bookworm r0, but I think bookworm r0 is the earliest it can be. If we're scared of commitment, we could say that merged-/usr is the only supported layout for bookworm, but not pull the trigger on allowing unmerged-/usr code paths to be removed until bookworm+1 - but that would leave those code paths untested, and we know that untested code usually doesn't work. Strictly speaking, the cutoff in the timeline I proposed isn't bookworm r0, it's the first time you update from testing/unstable *after* bookworm r0. > ¹ 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. Well, we have the usrmerge package, so an implementation exists. It isn't perfect, and I hope that between now and the bookworm freeze, we can get a better migration path than `apt install usrmerge` as currently implemented (either in a new revision of the usrmerge package, or elsewhere); but it mostly works in practice. Doing what usrmerge does from a maintainer script is pretty scary from a robustness/interruptability point of view. Without my Technical Committee hat on, one route that I think should be considered is deferring the migration until the next boot and doing it from the initramfs, so that nothing else will be concurrently writing to the root filesystem. In terms of the mechanics of upgrading to bookworm, this would mean that all the bookworm packages get installed into an unmerged-/usr system running the bullseye kernel, and then the next reboot switches to a merged-/usr system running the bookworm kernel. The reasons Marga is being careful not to mandate any specific implementation in that message are that detailed design is specifically outside the Technical Committee's role, and that the TC doesn't want to constrain the implementation: whatever implementation plans people come up with, we would like the best one to be used, and we certainly don't want a TC resolution that preemptively forbids the best implementation because we hadn't thought of it at the time. > ³ 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. It certainly wouldn't be ideal for the security team (or package maintainers) to have to fix package reproducibility before a security update can be released, but I think we already have situations where the security team have to fix a FTBFS, test failure, Lintian autoreject or other non-security-related RC bug before a security update can be released. If we say that merged-/usr vs. unmerged-/usr non-reproducibility is RC, then it's "just" another class of RC bug that might need fixing before the package can be updated successfully. smcv
