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.
Note that packages built in a non-merged-/usr chroot work fine on a
merged-/usr system, as long as they don't contain both /foo and /usr/foo
(which is more likely to be a fact about the package than a fact about
the chroot, and would already be considered RC since buster).
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).
The reason for this choice of sequencing is that we *do* care about
existing installations (specifically, those that were installed before
buster or with non-default debootstrap options, and have been upgraded
since then without installing usrmerge or carrying out the /usr merge
some other way).
> > 2. bookworm release: systems must transition at or before the upgrade to
> > bookworm (bullseye systems are not required to transition until/unless
> > they are upgraded)
>
> The "at" in this sentence means that all bookworm packages must support
> unmerged
Yes, that's what I said: package maintainers must not assume/require
the new layout until step 3, which is when they start uploading to
unstable post-bookworm. If package maintainers want to be able to
assume/require merged-/usr sooner, then they are going to be disappointed,
but that's part of the price we pay for having upgrades that work.
In the timeline I outlined, the target layout (merged /usr, according
to the technical committee resolution) is the only thing officially
supported *for bookworm as a whole* - but every[1] package in bookworm,
individually, must support both the target layout and the "other" layout
(the same as they did in bullseye), because partial upgrades are a thing.
I think this works both ways round: if, instead, we wanted to "rewind"
to the situation of a few years ago where merged /usr was not possible,
by passing through a release-time flag day after which all supported
systems must be unmerged-/usr, then the soonest that package maintainers
could assume/require an unmerged /usr (and therefore start to ship both
/foo and /usr/foo) would be the day after the bookworm release.
smcv
[1] Depending on how you look at it, packages like usrmerge that are part
of implementing the transition might be considered to be an exception
to this - although they do get installed on a system that does not
have the target layout, in order to turn it into a system that does,
so you could also say that they do (and must!) support the other layout.
