On Thu, 01 Aug 2024 at 20:00:40 -0700, Russ Allbery wrote:
> I just know that I've seen a lot of code that uses version
> numbers or code names this way, mostly in things like Puppet rules. Most
> of the time people will probably get this right, but there are some
> obvious potential mistakes such as coding a condition that says 13 behaves
> the same as 12 (but the eventual release won't) or that 13 always behaves
> in some new way (but testing systems that weren't upgraded to the released
> version 13 don't and instead behave like 12).
I think the only right ways to handle version-dependent conditions
are either feature detection (looking for the feature of interest, e.g.
dpkg --assert-versioned-provides), or looking at the version number of the
(possibly backported) package of interest (e.g. dpkg-query -W systemd),
or if neither of those is feasible, something like this pattern:
if major_version <= 11:
do old things
else if major_version == 12:
do things suitable for bookworm
else:
assume testing/unstable/future and do new things
with more or fewer "else if" depending on the number of major versions
with divergent behaviour that you aim to support. All of those patterns
would work without a VERSION_ID in testing/unstable, or even without a
VERSION_CODENAME.
But, obviously, third-party software doesn't always get this right, and
will sometimes say things like "all Debian systems except testing/unstable
have 32-bit time_t on armhf" - which happens to be true *today*, but will
immediately become false when we release trixie.
> The most mistake-resistant approach would be to give
> testing some *other* code name that isn't trixie, and only give the code
> name of trixie at the time of release, but that's also weirdly different
> from how we use codenames in the archive structure
That also breaks some of the design principles of the
unstable -> testing -> stable flow, which are that testing should be
approximately equivalent to a previous state of unstable (one where
everything worked acceptably together), the next stable should be
functionally equivalent to a late-freeze version of testing, and as
little as possible should change as we cross release milestones, to
avoid perturbing packages' behaviour.
We don't 100% stick to those design principles, because getting all of
unstable into a state where it works acceptably together and is ready
to migrate is not actually feasible most of the time, so instead we
migrate a package or a group of packages at a time - but the design goal
is that there are no surprises when testing is updated, because every
behaviour change has already been seen before, in unstable. So I can
understand why Santiago is reluctant to have testing and unstable be
obviously, identifiably different.
I think the release team needs to be involved in the decision of how
testing and unstable should be labelled, because it's the release team
that is responsible for the flow of packages from unstable into testing
and the flag-day transition from "trixie is testing" to "trixie is stable",
and it's also the release team that would have to deal with the fallout
if packages changed their behaviour (possibly during hard freeze!) when
they saw /etc/os-release change from unstable to trixie.
In other distributions like Fedora and Ubuntu, the branch that is going
to become the next stable (Fedora rawhide, Ubuntu devel) is already
labelled as though it *was* the next stable. The Debian equivalent of
this would be to label testing as Debian 13, trixie, starting as soon
as the branch opens (I often call it something like "a Debian 13 alpha"
when I need to communicate its status to developers outside the Debian
bubble) and I think that would be a reasonable thing to do.
The unusual thing about Debian is that we have not one but two "future"
branches, unstable and testing, together with the unstable -> testing
migration, *and people actually use unstable*. In Fedora, I believe
new packages go directly to rawhide (the Debian equivalent would be not
having unstable, and uploading directly to testing), and the VERSION_ID
in rawhide is the major version that the *next* Fedora release will
have (so, yes, the Debian equivalent would be to have had VERSION_ID=13
starting from the beginning of trixie).
In Ubuntu, they do technically have an equivalent of unstable (they call
it "proposed"), but my understanding is that nobody outside the Ubuntu
infrastructure actually runs it on their computers - the ability to
install it on systems other than buildds isn't advertised. So if it's
mis-labelled, there's no actual practical impact, because it's very
close to their equivalent of testing, and nobody is running third-party
software on it anyway. In terms of how it's used, it's more like Debian's
buildd-unstable branch, used on buildds, QA/test infrastructure and
nowhere else.
The closest equivalent of what Fedora and Ubuntu do would be to label
both testing and unstable as though they were some sort of Debian 13
prerelease, but not distinguish between the two. But Luca is asking for
unstable images/chroots/installations to be machine-readably different,
even if they happen to contain all of the same packages at the same
versions (other than base-files), and I think that's because unstable
has more users than Ubuntu proposed, and is typically further away from
testing than the gap between Ubuntu proposed and devel.
So I think Luca really has two distinct change requests here, not just one:
1. Label testing as Debian 13 starting from the beginning of the trixie
cycle, and the equivalent for each future cycle
2. Label unstable as something that differs from testing
and it would be technically possible to have both, or neither, or accept
(1.) but reject (2.).
I personally have a lot of sympathy for wanting (1.) - as I said, when
I'm communicating with developers outside the Debian bubble who don't
know our processes, I tend to refer to both testing and unstable as some
sort of prerelease, alpha or preview of Debian 13, because that's close
enough to true. I am much more hesitant about (2.), because testing and
unstable are more similar than they are different, and more similar to
each other than they are to their state 6 months ago.
smcv
(not a TC member)
