Bug#914287: lsb-release: please parse /usr/lib/os-release and deprecate /etc/lsb-release
On Wed, 2 Jan 2019, Didier 'OdyX' Raboud wrote:
> /etc/lsb-release is a Debian-specific file, that the LSB spec doesn't mention.
> Only the `lsb-release` command should be used:
Yes, which is what the rules files are using. We just need to
be able to override the normal result for sid chroots.
> DISTRIB_RELEASE goes in `lsb_release -r`, and is taken from
> `/etc/debian_version`, which is in /etc, so is overridable.
>
> DISTRIB_CODENAME goes in `lsb_release -c` and is also taken from
> `/etc/debian_version`, but when this contains "buster/sid", it falls back on
> parsing `apt-cache policy`.
Hm, perhaps, but apt-cache output is tricky if multiple
distributions are in use (e.g. ports architectures have
unreleased in addition).
> When built in/for Debian, packages:
> * should really not rely on the output of `lsb_release`, but
I doubt that. This is a _really_ useful tool, and having only
this one makes it easy to have consistent behaviour for all
such packages, if lsb_release plays nice. (Which is what I’m
asking for.)
The packaging of OpenJDK is an in-tree example using this.
I’m similarily using this for a company-local package.
> * really *must not* depend on `/etc/lsb-release` to second-guess `lsb-
> release`.
We don’t do that, we just run lsb_release with various parameters.
> That said, if you still think lsb_release should allow overrides from that
> Debian-specific file, please file another bug, ideally with a patch that lets
> `lsb_release` be noisy about its usage.
I do still think so, not sure about the wording, but I’ll
probably file the bug once I get to that. (I only just saw
this during a dist-upgrade, and am working with other fallout
at the moment.)
Thanks,
//mirabilos
--
15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
Reply to: