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 men=
tion.=20
> 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.
>=20
> 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=20
> 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=E2=80=99m
asking for.)

The packaging of OpenJDK is an in-tree example using this.
I=E2=80=99m similarily using this for a company-local package.

> * really *must not* depend on `/etc/lsb-release` to second-guess `lsb-
> release`.

We don=E2=80=99t do that, we just run lsb_release with various parameters.

> That said, if you still think lsb_release should allow overrides from tha=
t=20
> Debian-specific file, please file =09another bug, ideally with a patch th=
at lets=20
> `lsb_release` be noisy about its usage.

I do still think so, not sure about the wording, but I=E2=80=99ll
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
--=20
15:41=E2=8E=9C<Lo-lan-do:#fusionforge> Somebody write a testsuite for hello=
world :-)