On Wed, 15 Sep 2021 at 11:46:11 +0100, Simon McVittie wrote: > 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.
Here it is: https://salsa.debian.org/debian/tech-ctte/-/blob/master/994388_merged_usr_advice/draft.md Edits and merge requests welcome. I suggest we use merge requests for substantive changes. This is a collection of various pieces of advice. I hope that this is sufficiently uncontroversial among the TC that we can improve the wording where necessary, then take a unanimous or close-to-unanimous vote "yes > further discussion" when we feel that it reflects consensus? If there are individual bits that are more contentious, then I suggest we vote on them as formally or informally as we are comfortable with, then make the formal resolution reflect the results of those votes; alternatively, we could kick out anything more controversial into a separate resolution if we need to. Because this is advice to maintainers about decisions that, in some cases, they are making right now, I would like to keep this moving and try to reach a consensus we can announce to debian-devel-announce soon. Questions for the committee: - §(Definitions and current status): Does everyone agree with my characterization of where we are now? - §(Upgrade path from Debian 11 to Debian 12): Does everyone agree with what I've written here about the implications of #978636? I've tried to be careful to distinguish between the Debian 12 stable release and the state of testing/unstable during the development cycle; better wordsmithing welcome. - §(Upgrade path from Debian 11 to Debian 12): Is the last paragraph "If a suitable transition mechanism is not available by the time the Debian 12 freeze is reached..." necessary, or is it implicit that *obviously* we won't demand that the project carries on with merged-/usr if it turns out not to be possible? - §(Testing and QA): Do we want to recommend this? - §(Building packages): Does everyone agree with my interpretation of what we agreed in #914897 and its implications? Do we need to make a recommendation for the Debian 12 development cycle, or is it enough to assume that the "middle" option that we resolved in #914897 continues to be our opinion? I assume our advice power doesn't extend to unilaterally declaring a class of bugs to be RC, but we can certainly advise the release team and package maintainers that they *should* consider a class of bugs to be RC; if they follow our advice, great, and if they don't, we can consider whether we need to overrule in individual cases. - §(Building packages): I almost wrote an extra paragraph about how this class of bugs becomes a non-issue when merged-/usr is the only supported layout - but actually it doesn't! If we consider building packages while having /usr/local/bin/sed to be a supported thing you can do, then we need to ensure that /usr/local/bin/sed doesn't get hard-coded into the resulting package, and the steps you take to make that happen are the same as the steps you take to fix this class of bugs. - §(Moratorium on moving files' logical locations into /usr): I think we should stop moving files into /usr on an individual basis, at least until the consequences are fully understood, and perhaps for the whole Debian 12 release cycle (after which, assuming merged-/usr goes as we have recommended, maintainers can swap their logical location without needing a transitional mechanism any more). Implementing merged-/usr as the only supported layout means that moving files into /usr on an individual basis is mostly unnecessary, because it has no practical effect any more. Note that my opinion on this is consistent with Adrian's request to overrule the debianutils maintainer and require installkernel and run-parts to be moved back to the rootfs. We should make sure that whatever we decide here is consistent with the way in which we overrule or decline to overrule the debianutils maintainer. > - 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.) Ansgar pointed out on IRC that of course I meant to say debhelper here, not debootstrap. The version of debhelper in git reverts the change that previously moved systemd units from /lib/systemd/system into /usr/lib/systemd/system, but at the time of writing that revert is not in a release. smcv