El 31/3/22 a las 13:42, Marc Haber escribió:
Package: base-files
Version: 12.2
Severity: wishlist
Hi,
/etc/os-release in testing and unstable does not set VERSION, VERSION_ID
and VERSION_CODENAME, which causes, for example, ansible to just emit
"NA" as distribution version, which forces me to special-case testing
and unstable.
I see possible issues with testing migration of base-files, ruling out
having different values for sid and testing until shortly before the
relase of a new stable version, but would it be possible to set one of
those values (maybe at least VERSION_CODENAME to "testing/unstable" or
"bookworm/sid") so that the special-casing of the version number is not
necessary any more?
I bet that most installations having a configuration management system
have a small number of testing/unstable boxes in their fleet to
anticipate for possibly necessary changes, and having to special-case
the development versions kind of contradicts this intention.
By definition, testing and unstable only have codenames, not version
numbers, this is something with a long tradition in Debian and I don't
see a strong reason to change it, but I am willing to add
VERSION_CODENAME if it helps, and release managers do not object.
But before that I'd like to know what are the other alternatives.
Gioele Barabucci wrote:
> The string "bookworm/sid" is already present in `PRETTY_NAME` and in
> `/etc/debian_version`, so it should not be a problem to have it also
> in `VERSION_CODENAME`.
Using the string "bookworm/sid" makes sense because it's user-visible,
but for VERSION_CODENAME the only string which would make sense to me is
"bookworm". This way, nobody will have to rewrite any script when
bookworm becomes stable.
Also, it should be clear for everybody that we can't make everybody
happy with this. We would use "bookworm" and nothing else. This could
help those who are betatesting bookworm as stable. Those willing to
betatest anything else should understand that we can only put a single
codename for both testing and sid.
Petter Reinholdtsen wrote:
> I discovered it when the Github CI build started failing for LinuxCNC,
I'm curious about what lsb_release does and how does it.
Is this the first time that lsb_release fails to guess the codename?
What did it do in the past?
Maybe there was there a time in which lsb_release looked at
/etc/apt/sources.list to determine the Debian version which was
installed, or it was some other tool?
Thanks.
