On Thu, 01 Aug 2024 at 16:54:20 +0100, Luca Boccassi wrote:
> The second [objection from the base-files maintainer] is pushing forward a
> philosophical explanation according to which testing and unstable are
> not actually different images, but they are one and the same (two sides
> of the same coin is the expression used). While that might be true in a
> philosophical sense, this is a practical matter, and it concerns only
> the os-release specification and its implementation. In such context,
> testing and unstable are different and independent images, built from
> different and independent archives of packages. For example, at any
> point in time you can do:
>
> deboostrap testing /tmp/a
> deboostrap unstable /tmp/b
>
> and if your shell history is lost, you have no reliable, stable,
> distro-agnostic way to identify what exactly /tmp/a and /tmp/b are.
But, let's continue your example: suppose you ran those commands back in
January. Now, 6 months later, run similar commands again:
debootstrap testing /tmp/c
debootstrap unstable /tmp/d
With your proposed labelling of testing and unstable as being fundamentally
different, you would have:
/tmp/a: testing from January, labelled as testing (or trixie or Debian 13)
/tmp/b: unstable from January, labelled as unstable
/tmp/c: testing from July, labelled as testing (or trixie or Debian 13)
/tmp/d: unstable from July, labelled as unstable
But, contrary to that, the differences between a and b will be relatively
small, and so will the differences between c and d; whereas the differences
between a and c will be large (even though they're both labelled as
testing) and so will the differences between b and d.
For example, a and b will have glibc 2.37, but c and d will have 2.39,
with whatever behaviour changes have happened in the last 6 months.
Similarly, neither a nor b has been through the t64 transition, but
both c and d have.
I think the most important fact about all of these chroots is
"it's strictly newer than Debian 12, so expect some behaviour
changes". Precisely how much newer, and precisely which behaviour changes,
is not such a simple question to answer: it depends which package's
behaviour you're interested in, and if you want to answer that question,
the only way is to look at individual packages, so that you can tell
whether they were last updated in January or whether they have been
updated to July's version.
smcv
(not a TC member)
