Luca Boccassi <bl...@debian.org> writes: > 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.
This is not true of a testing image, which is indeed a rolling release (with a somewhat odd variation in the frequency with which new packages are rolled into the release) that never gains security support, never passes to the LTS team, and never goes EOL. So whether this is true of an image installed from the current testing repository depends on the apt configuration in a way that is not captured by os-release under your proposal, namely whether it is configured to point to testing or to trixie. It's the exact same package set, but a completely different lifecycle. This is somewhat similarly true of stable vs. bookworm, but pointing to stable rather than bookworm is generally not encouraged because the sudden upgrade behavior when we release a new stable can be surprising in a way that is generally the opposite of what one wants from using stable. With testing, however, this is a standard configuration that is often preferable to using the codename, depending on what goals one has for running a testing image. For example, every testing image that I have points to testing, not to trixie. > 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. I think there is no way to fully satisfy that purpose in Debian without doing something dynamic based on the apt configuration. Your proposal provides a different approximation that better captures one aspect of the lifecycle, but still does not achieve the semantics you're arguing for in the abstract. -- Russ Allbery (r...@debian.org) <https://www.eyrie.org/~eagle/>
