On Fri, 2 Aug 2024 at 10:09, Simon McVittie <s...@debian.org> wrote: > > 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.
If you chroot into /tmp/b after you create /tmp/d, and you update it, you will get content that matches /tmp/d, not /tmp/c (yes yes if you touched /tmp/b in some ways there will be subtle differences, and weird breakages might happen from time to time, but you know what I mean). sid remains sid, it will never be trixie, it will never become released with security support, then move to ELTS, and then go EOL. A particular instance might have some out of date content, but that's true of every OS tree in the universe, but it fundamentally doesn't change its identification from the point of view of os-release. The fact that some content might match the content of other releases doesn't change anything in the specific context of os-release - again it's fine to have a philosophical discussion on what actually constitutes a pipe, but this is not the purpose of this ticket - in fact, we have many many packages that never get rebuilt, and that are bit-by-bit identical from oldoldstable to oldstable to stable to testing to unstable. Does it mean that os-release in bullseye is wrong to identify it as bullseye and should say 'sid' instead, because some packages are identical and indistinguishable between the two? This is trying to ascribe a meaning to os-release that it really doesn't have, and nobody I know of uses it for. Because it doesn't tell you "yes this is exactly up to date at the time you are reading it". It tells you, "this is what this vendor tree was, at the time it was last updated or created", and yes, this is useful and needed information to convey. If you create an Archlinux or a SUSE Tumbleweed vendor tree now, and another one next year, they will be massively different. os-release will still, correctly, say the same thing. Because it is not a statement about updated-ness, it's a statement that captures the identity of a vendor tree at the point in time it was touched. As mentioned already in a separate mail, we actually have optional fields like BUILD_ID where timestamps can be added, if that needs to be tracked. A VERSION_CODENAME doesn't mean content will always be the same - it's not a reflection on every single bit of its content. It's the identity of the tree that matters. And again to bring up the same real world example from the other mail, if you do debootstrap bookworm in August last year, and you do that again in August 2026, the content will be wildly different in terms of packages, with tons of upgrades that in some cases, like the kernel, change the behaviour massively. But they are still both Bookworm OS trees from stable releases.
