On Tue, Nov 09, 2021 at 08:44:52PM +0000, Simon McVittie wrote:
> 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:
> > (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).
Yes, any Debian 12.x package (even the very last security fix build for
it) needs to be installable on a Debian 11.y system as it could be part
of the upgrade from 11 to 12 and as it has no idea if its the first or
last package in that upgrade (within reason) it has to work on 11 as
well as on very-very-close-to-12.
As such, if you promise 11.x to 12.y upgrades I would expect 12.x to
12.y to work just as well as 12.x is very-very-close-to-12(.y).
If you say 12.x to 12.y isn't supported on unmerged it means effectively
that all "cattle" have to be constantly recreated as you can't have
a single package be considered an 'upgrade', they all need to be 'new
install' while e.g. installing build dependencies (as ironically a fully
upgraded 12 system is indistinguishable from an upgrade-in-progress-from-
11 system which just happens to install a bunch of new packages in the
end).
Its also quite a disaster for all systems already technically bookworm
like testing and sid as any upgrade, including to the release 12.0, will
be unsupported in your logic. Unsupported machines (aka our buildds)
building supported packages seems sad and I thought we had talked about
this before.
> > (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.
As the transition hasn't started everyone not already merged is currently
deferring it. That is true for those who upgrade daily as well as for
those people who seemingly only upgrade their sid systems once in a blue
moon. So, at which point have all those systems stopped deferring?
I would say that the first time you can say with absolute certainty that
a given system is no longer deferring the transition is the moment an
unpack of a trixie pkg is attempted as skipping releases is not
supported. All unpacks before that could happened on an unmerged
system as that system might very well be in the process of upgrading
from 11 to 12 at the moment.
(and btw, what I meant with me opting out for a while was delaying the
upgrade of my sid "beasts" to a more exciting problem space than the
first possible moment as that wouldn't be much of a test for apt, /usr
merge and all those other packages installed around here. If I am
asking for an upgrade path its only fair to not take the easiest road
of transitioning to merged before anything could implicitly require
it and hence fail for less lucky people not equipped to deal with it.
My "eldritch horrors" are fine and behave, thanks for asking. 😉)
Best regards
David Kalnischkies
Attachment:
signature.asc
Description: PGP signature