tl;dr: I would prefer it if the usrmerge variation continues to be
exercised for the testing suite for the foreseeable future.
On Tue, 17 Aug 2021 at 09:16:01 -0700, Vagrant Cascadian wrote:
> The short of it, as I read it, is that non-usrmerge systems will be
> unsupported for bookworm, or did I misread that?
Assuming that TC resolution #978636 remains in effect:
There's unsupported, and there's unsupported; and I think we need to
distinguish between bookworm-as-testing, and bookworm-as-a-release.
For the reasons discussed elsewhere in this thread, the earliest point
at which package maintainers will be able to assume/require that their
package is installed onto a merged-/usr system is in around 2 years' time,
*after* bookworm r0, when the bookworm+1 cycle opens in testing/unstable.
This is because the packages that make up bookworm need to be installable
onto pre-bookworm, non-merged-/usr systems, otherwise we don't have an
upgrade path. We don't support skipping a release, so the packages in
bookworm+1 can safely assume that the system was fully upgraded to
bookworm first.
So for bookworm r0, we can *document* non-merged-/usr as unsupported,
and encourage/require/help users to transition systems to merged-/usr,
but in practice all the packages (except for those that are actively part
of the transition) need to behave as though it's still supported. When
the post-bookworm floodgates open and everyone is looking anxiously
at the buildd load graphs, *that* is the point at which packages can
validly start doing things that only work on merged-/usr systems. Does
that make sense?
> * 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).
That variation is implemented by installing the usrmerge package, and
installing usrmerge has no effect on systems that are already merged-/usr;
so if a transition during the bookworm release cycle results in the
"base" bookworm chroot being merged-/usr already, that variation will
become meaningless but harmless. I think that's fine.
Until the "base" bookworm chroot becomes merged-/usr, please keep
applying usrmerge before the second build. We need to monitor the status
of packages whose contents differ when built on a merged-/usr system,
because as mentioned elsewhere in this thread, I think that needs to be
treated as a RC bug (if it isn't already). If packages vary in this way,
we need to get that variation fixed in testing, not just in unstable,
so having test coverage for that will be helpful.
Side note, I'm trying to be careful to distinguish between merged /usr
(a filesystem layout) and the usrmerge package (one implementation
of the transition from a non-merged-/usr filesystem to a merged-/usr
filesystem). You can have merged-/usr without ever having installed
usrmerge: new d-i installations of buster and bullseye are in that
situation.
smcv
