On Sun, 4 Aug 2024 at 00:25, Russ Allbery <r...@debian.org> wrote: > > 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.
I do have 'stable' in my configuration on this machine, intentionally. It doesn't suddenly become incorrect that os-release says VERSION_ID=12 VERSION_CODENAME=bookworm, because it _is_ bookworm right now. Once the next stable is out, it will be upgraded, os-release included and it will say VERSION_ID=13 and it will still be correct. Same for testing. This is not incompatible at all with os-release, and in fact it works very nicely - it just means "when this reaches the point of flipping to a different stage in the lifecycle, upgrade me to the next version automatically when such process runs next". If you build an image, _of course_ the metadata will be correct at the point in time that image was created, if you don't touch it, it cannot magically change, that's ok, and in no way contradicts anything I've said or anything in the os-release spec, and I don't see how it could - it would be useless if it broke 5 minutes after an image was created. None of this means that bookworm or trixie are rolling releases - they are not, they will both be EOL and need replacements. If you build a testing image or a stable image or an oldstable image you are just taking advantage of aliases to automatically move between different releases when they reach certain points in their lifecycles - we call these 'aliases', correctly, which reflects this fact. If you run an upgrade workflow, however that might look like, the content will change - that's ok! It's the point of doing upgrades. If it's configured to do so, it will be a different release after the upgrade, and its new metadata will reflect that. What it could use to make it even more useful, is adding SUPPORT_END= and RELEASE_TYPE= so that I can get extra information out of it - however, these are cherries on top. And I don't _think_ we have fixed EOL dates that can be set pre-emptively, while other distros do, so it would have to be added on EOL date which is less useful, but perhaps worth considering nonetheless. Again, not a deal breaker. > > 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. Already explained above how this can and does work.
