Bug#994388: tech-ctte: More specific advice regarding merged-/usr and implications of #978636
Package: tech-ctte
Severity: normal
As discussed in our last meeting, I think we should issue more specific
advice about merged-/usr, and in particular about what #978636 means for
maintainers right now.
Constitutionally, I'm asking the TC to use its power to offer formal
advice (Debian constitution, §6.1.5).
As for what that advice is, I'm open to suggestions, but I'm drafting
some possible wording, which I'll upload to
https://salsa.debian.org/debian/tech-ctte/ when I have a bug number
for it.
Some questions that I think we need to answer explicitly:
- What do we mean by merged-/usr? (We already said this in #914897, but
I think it's worth reiterating that symlink farms are not it.)
- Is it OK for packages in testing/unstable during Debian 12 development
to assume/require a merged-/usr system? (tl;dr: some maintainers think
the answer is yes, but I think the answer is no.)
- When will it be OK for packages in testing/unstable to assume/require
a merged-/usr system? (tl;dr: some maintainers think the answer is
"right now", but I think the answer is "when the Debian 13 cycle begins"
and not before.)
- Should maintainers proactively move files in packages from the root
filesystem into /usr? (tl;dr: I think they should not, at least until
the implications are better-understood.)
- Should maintainers of tools, e.g. debootstrap, proactively move files
in packages from the root filesystem into /usr, e.g. systemd system units?
(tl;dr: I think they should not.)
- Are packages built on a merged-/usr system required to work correctly
on a non-merged-/usr system? If they are not, is it RC?
(I think they are required to work, and it should usually be RC if
they don't; constitutionally I don't think we can unilaterally declare
a class of bugs to be RC, at least not while using our "advice" power,
but we can certainly recommend that maintainers and the release team
should consider them to be RC.)
smcv
Reply to: