On Tue, 6 Aug 2024 17:55:23 +0200 Wouter Verhelst <wou...@debian.org> wrote:
- Gioele's message is about reimplementing lsb_release in terms of
os-release.
Not really. lsb_release has already been reimplemented purely in terms
of os-release since bookworm. Even the older Python version used
os-release as the main source of truth, if available.
Surely the reason that os-release exists is not "so
we have a way to implement the lsb_release script".
Not "the" reason, but one of the reasons. lsb_release is explicit
referred to in the FAQs: http://0pointer.de/blog/projects/os-release
In fact, if that
were the only reason, then we could do away with os-release entirely,
implement lsb_release for Debian in terms of parsing apt
configuration, and we wouldn't even be having this discussion.
This is what I would like to highlight:
The status quo until Debian 11 was that users of Debian were be able to
_distinguish_ between "testing" and "unstable". [1]
That ability was however provided by lsb_release instead of base-files.
This ability of lsb_release to tell "testing" apart from "unstable"
(often with wrong results, see the amount of bug reports) was used by
many users and applications. (And I know because of the bug reports I
received once lsb_release started being Provided by
src:lsb-release-minimal).
My opinion is that lsb_release should not be in the business of guessing
if a OS is "testing" or "unstable". Self-identification is a task of the
OS itself.
Another opinion of mine is that LSB and lsb_release are legacy
interfaces not suited for the modern world. This is also the opinion of
Debian since Debian 9 (stretch, 2015, [2]).
So the modern place where to implement the distinction that was there
before Debian 12, is the current cross-distro facility /usr/lib/os-release.
[1] https://bugs.debian.org/1038383#10
[2]
<https://www.debian.org/releases/stretch/amd64/release-notes.en.txt>,
section 5.1.6
--
Gioele Barabucci
