Bug#1077764: Ruling request on os-release specification implementation
On Fri, 2 Aug 2024 at 18:01, Russ Allbery <rra@debian.org> wrote:
>
> Simon McVittie <smcv@debian.org> writes:
> > On Fri, 02 Aug 2024 at 09:07:12 -0700, Russ Allbery wrote:
> >> Luca Boccassi <bluca@debian.org> writes:
>
> >>> It is correct as-is. VERSION_ID is meant to identify a release, not
> >>> updates or point releases. A release as in, Debian Bookworm, or Fedora
> >>> 40, or Ubuntu Noble, and so on.
>
> >> Why would you not want to identify point releases? This really
> >> surprises me.
>
> > I think the idea is that two releases have a different VERSION_ID if and
> > only if they can both be fully up to date, but still remain
> > different. If we make the analogy of git, VERSION_ID labels a branch,
> > not a tag.
>
> Oh, thank you, this was not at all obvious to me. If this is indeed the
> case, that would be a useful clarification to add to the specification.
>
> This also explains the desire to identify testing as trixie, but not
> identify unstable as trixie. If one configures a testing system to point
> to trixie, then fully updating it will move it into the stable release
> when the stable release comes out. However, if one points a system at
> unstable, that system will never become a trixie system and will always
> continue to point to a different release.
>
> This is not an entirely clean analogy, since it's also possible to point a
> system at the testing suite directly, rather than using the code name, in
> which case that system will also never become trixie. So in that sense
> testing is simultaneously both trixie and not trixie depending on exactly
> how you configure apt.
>
> This sort of ambiguity is, I think, part of why this proposal generates so
> much discussion. Debian simply doesn't currently have clean semantics for
> testing. It exists in a sort of quantum superposition where it is
> multiple things simultaneously for different people, and this proposal is
> trying to label it in a way that collapses that state to match the mental
> model of one group of people, invalidating the mental model of a different
> group of people.
If you instantiate it as 'testing', using that keyword through your
configuration, including apt, then it will be updated to the next
version when that is created in the archive. So it is still trixie
today, and tomorrow it will be forky, and everything, including the
os-release file, will be updated accordingly with my proposal.
>From the point of view of the os-release specification, this is
exactly the same as using 'stable' to build and manage an image. Today
that is bookworm, yesterday it was buster, tomorrow it will be trixie.
It is still correct that today os-release says it's bookworm. Once it
is upgraded, the os-release will be upgraded too and say 'trixie'
because that's released and that's what the 'stable' alias points to.
It's the same installation, and it gets upgraded to a new release -
that's entirely supported by the os-release spec. That's the same if
you are tracking 'testing'. And that is why in my very first mail at
the top of this bug, I said that testing is _not_ a rolling release,
because there's a -1 and a +1 and it has a limited lifespan. Support
status is different than stable, but there are other fields to
indicate that, and again it applies just as well to oldoldoldstable.
So again, while I see why there could be different points of views and
some confusion around what means what, my view is that this proposal
doesn't really introduce anything new, and doesn't change anything
that happens today in any fundamental way. As already mentioned, I do
not see anything fundamentally incompatible between the os-release
concept and the unstable or testing concepts as they are today,
whether they are considered with their codenames or the aliases.
Reply to: