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