Re: merged-/usr transition: debconf or not?
On Tue, 09 Nov 2021 at 19:01:18 +0100, David Kalnischkies wrote:
> On Tue, Nov 09, 2021 at 03:21:25PM +0000, Simon McVittie wrote:
> > > 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*
>
> Yes, I meant that indeed… should have used codenames after all.
To be clear about this: when drafting the TC resolution, I did not intend
for this to "allow the transition to be deferred" and still leave you with
a supported system.
All I was aiming to do there was to make it possible to create an
unsupported, not-quite-Debian system that our QA infra can compare with
the supported Debian system that closely resembles it, so that for example
if a package builds differently on unmerged-/usr and merged-/usr systems,
we can flag it as "this is likely to break upgrades" and look more closely.
> > 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.
>
> Sure.
>
> (Minus that for 12 it is technically still supported as long as it
> remains 12
No, it doesn't have to be supported, and the TC resolution explicitly
said that it doesn't have to be supported.
What *does* need to be supported is the upgrade path from 11 to 12,
or from current testing (11-and-a-bit) to 12, with any ordering of apt
transactions that doesn't violate the packages' dependency conditions -
and the TC's reasoning was that the simplest, most conservative, most
robust way to make sure that continues to work was to mandate that all
Debian 12 packages, individually, are installable onto unmerged-/usr
Debian 11 (assuming that "installing a package" implies installing its
dependencies, in any order that apt/dpkg consider to be valid and not
breaking any dependency relationships).
> (Perhaps it comes with the job as apt maintainer, but I don't "discard
> and redo" systems or even chroots… upgrades until hardware failure…
> my current build chroots are from 2013. So I can totally see me opt-out
> first and later in… although probably more with apt_preferences)
For full systems that are managed as full systems ("pets" in the cattle
vs. pets terminology), sure, do that; the Debian installation I'm typing
this into has been copied from several older machines. However, deferring
or avoiding the merged-/usr transition on these systems is not intended
to be something that is considered valid for bookworm.
For installations that are meant to be predictable, like build chroots
and the chroots/containers used for automated QA systems, keeping a 2013
installation and successively upgrading it comes with a significant risk
of ending up with an installation that nobody else (including you, if
the underlying hardware fails!) can replicate without starting from a 1:1
backup of that installation. I would not recommend this approach:
I think installations that are meant to be predictable should be "cattle".
I had intended that preventing the /usr merge (with debconf preseeding or
Marco's flag file or whatever) would be something that people should only
be doing in those "cattle": the steps to reproduce those systems would
include applying the debconf preseeding or creating the flag file.
smcv
Reply to: