El 12/10/22 a las 17:42, Gioele Barabucci escribió:
Package: base-files
Version: 12.3
Dear base-files maintainer,
this is a followup to #1008735 to provide 3rd-party software authors
with better clarity (and confirmations) about Debian's approach to the
information shipped in `os-release`.
A quick summary: `os-release(5)` is the only currently supported
cross-distro API to retrieve operating system identification data.
With this in mind, it seems correct, based on the content of the
`os-release` file shipped by `base-files`, to state that:
1. Debian has no concept of "release version" (codified in `os-release`
in `VERSION_ID`) for operating systems built using the software
published in the suites "unstable" and "testing". These operating system
instances just exist and have no version.
That's correct. In theory, Debian bookworm will not be Debian 12 until
it's released as stable.
(For comparison, other rolling distros publish version IDs for
snapshots. For example openSUSE Tumbleweed uses a date like "20220926",
Fedora rawhide uses the upcoming version number "38".)
In practice, we put the correct version number in os-release a few
months before the actual release, so that everybody can test bookworm as
if it was already stable. This happens sometimes sooner and sometimes
later, you can check this by reading base-files changelog.
But this is done just a few months before the release and it's not
expected to be there for the entire life of the testing distribution.
Sometimes people report this as a bug, but at this time, it is not,
because it's too early.
2. Debian does not desire to distinguish between OS installations based
on unstable and those based on testing using their codename (codified in
`os-release` in `VERSION_CODENAME`). The same string (the name of the
upcoming stable version) will be thus be used for both versions and it
should not be possible for 3rd-party software to distinguish between them.
> [...]
It would be more accurate to say it in this other way:
We do not desire to distinguish between bookworm and sid based on the
contents of os-release from base-files, because as it's explained in the
FAQ, the base-files package is uploaded for unstable and later
propagates to testing.
If there is another way to distinguish between bookworm and sid based on
some other thing (for example, whatever information is present in the
Release file in the ftp archives that apt-get update retrieves, as you
point out), it might be desirable to explore those other ways to
distinguish between bookworm and sid. But not in base-files.
[...]
Aside from the current situation summarized in the above points, could
you please consider again the idea of having the suite name in
`VERSION_ID` ("testing", "unstable") and meaningful codenames in
`VERSION_CODENAME` ("bookworm", "sid"), at least to simplify the work of
3rd-party software authors?
Sorry, no, I already did what I believe it's reasonable to do in
base-files. If there are things to improve, they should be done elsewhere.
In particular, making a bug in other packages to be blocked by this
particular bug in base-files, which I consider done, is not welcome.
Please don't do that.
Thanks.
