(Speaking only for myself, not the TC as a whole - but I wrote the first
draft of what became the TC resolution we're discussing.)
On Tue, 09 Nov 2021 at 15:19:53 +0100, David Kalnischkies wrote:
> On Mon, Nov 08, 2021 at 12:56:49PM +0100, Marco d'Itri wrote:
> > On Nov 08, Simon Richter <s...@debian.org> wrote:
> > > Right now, it is sufficient to preseed debconf to disallow the usrmerge
> > > package messing with the filesystem tree outside dpkg. Managed
> > > installations
> > > usually have a ready-made method to do so.
> > This is not really relevant, since the conversion is mandatory.
> > The CTTE stated that the only exception is "Testing and QA systems
> > should be able to avoid this transition, but if they do, they cannot be
> > upgraded beyond Debian 12", and my plan is to arrange for this with
> > a flag file.
For reference, the wording in the TC resolution is:
We anticipate that during the development cycle that will lead to
Debian 12, it is likely to be useful for testing and QA infrastructure
(such as autopkgtest, piuparts and/or reproducible-builds) to be able
to produce an installation of Debian testing/unstable that is not
merged-/usr, in order to be able to verify that packages targeted
for inclusion in Debian 12 can still be installed and/or built
successfully in a non-merged-/usr environment during partial upgrades.
As a result, we recommend that if there is an automatic migration from
non-merged-/usr to merged-/usr, it should be possible to prevent
that migration. **However, systems where that migration has been
prevented are not required to be fully-supported**, and in particular,
upgrading them to Debian 13 or to the state of testing/unstable
during development of Debian 13 should be considered unsupported.
(emphasis added in this mail, not present in the TC resolution)
As Marco implies, it was not my intention to have this as a
general-purpose way for change-averse sysadmins to avoid or defer the
automatic transition. I had intended this to be specifically there as a
way to do the testing and QA that will ensure that the transition can go
as smoothly as possible (for example, reproducible-builds does one build
with merged-/usr and one with unmerged /usr, and this should continue,
otherwise we'll lose the ability to detect packages that build differently
in those two scenarios, which in practice is strongly correlated with
packages that won't work on non-merged-/usr systems if they have been
built on merged-/usr).
I can see that if people are developing dpkg enhancements that allow it to
reconcile its view of the filesystem with merged-/usr by having a record
of the directories that "should be" merged (perhaps a --paths-aliased
analogous to --path-include?), then they would also benefit from the
ability to construct up-to-date systems that have and haven't undergone
this transition, so they can compare the two.
> As I see it the CTTE decision effectively allows the transition to be
> deferred until the moment you want to upgrade to 13.
I think you mean: until the moment you want to upgrade to testing after
Debian 12 release day. That's not Debian 13 *yet*, although you could
think of it as some sort of Debian 13~alpha, and the TC resolution allows
packages in testing/unstable to start requiring merged-/usr immediately
after Debian 12 is released.
I tried to make sure the TC resolution distinguished carefully between
Debian stable releases, and the states of testing/unstable that will
exist at particular points in the stable release cycle.
> So, wouldn't it make sense to go with an (extreme) low priority debconf
> question defaulting to 'yes, convert now' which [I think] non-experts
> aren't bothered with and users/systems wanting to opt-out for the moment
> (like buildds) have a standard way of preseeding rather than inventing a
> homegrown flag-file and associated machinery?
Speaking only for myself and not for the TC, I think a debconf question
would be OK as an implementation of this, but the debconf question should
indicate that the result of opting out is an unsupported system.
I would personally see this as a bit like using dpkg --path-exclude, or
downgrading packages: it's allowed, but it might break things immediately,
or it might have weird side-effects later on (even after the configuration
change has been reverted).
> As a bonus, if I had previously decided to forgo the automatic
> transition for whatever reason (lets say to test build packages on that
> box) I also have a standard way of triggering the conversion by calling
> dpkg-reconfigure on usrmerge at leisure before the 13 upgrade.
I had intended this to be for the class of systems that you would expect
to discard and re-bootstrap rather than upgrading (chroots, lxc/Docker
containers, virtual machines, etc. used for autopkgtest, piuparts,
reproducible-builds, etc.), where a way to undo the opt-out isn't really
necessary because the system is treated as disposable.
However, you're right that if a way to undo the opt-out is desired,
using debconf provides an implementation "for free".
smcv
