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