On Sat, 3 Aug 2024 at 19:28, Wouter Verhelst <wou...@debian.org> wrote: > > On Fri, Aug 02, 2024 at 11:35:54AM +0100, Luca Boccassi wrote: > > Testing and unstable have completely separate and independent > > archives, you can point an image builder to one OR the other, in > > isolation, and it will produce a fully complete and runnable and > > bootable OS tree. The fact that they might have some or even all > > content in common at particular points in time is orthogonal and > > unrelated to what the purpose of os-release is. > > I suspect this is the crux of your problem. Perhaps it might be useful > to explain what "the purpose of os-release" is, exactly? I suspect that > most people here see testing as more similar to unstable than not, and > in order for us to find common ground, understanding *why* this matters > for os-release might be useful.
I mentioned this a few times through the thread, but there now are walls upon walls of text, so it's worth repeating as it's very likely that it's lost in this miasma of words. A trixie image is now in development, will become stable at some point next year, will gain security support where it now has none, then it will pass to the LTS team, then it will go EOL and any installation will have to move to trixie + 1 which will be forky. The same happened to bookworm, the same will happen to forky. It is not a rolling release, because it has a limited lifetime, that begins, develops and ends. A sid image will never become stable, will never gain security support, will never pass to the LTS team, will never go EOL, such installation was always sid, continues to be sid now, will always be sid. It is a rolling release, because it has no beginning and no end, and an installed image simply carries on. Thus the lifecycles of a sid image and a trixie image are radically distinct and separate. They can be created individually and separately, they can be used individually and separately. They take different paths through time. The purpose of os-release is to identify images that have such differences, and give them metadata accurately describing their differing lifecycles, which are different and distinct, have different characteristics, reflecting in different fields being set, such as SUPPORT_END. The fact that content might be similar at some point in time is irrelevant for os-release, oldstable and stable also have some packages that are identical bit-by-bit and it doesn't matter at all: lifecycles are what matters, content does not.
