Bug#866778: lsb-release: lsb_release --all displays inconsistent information

Control: tags -1 +wontfix=20

Le samedi, 1 juillet 2017, 18.38:28 h CEST GT a =C3=A9crit :
>    * What led up to the situation?
> use of the command lsb_release --all
>=20
> :~$ lsb_release --all
>=20
> No LSB modules are available.
> Distributor ID: Debian
> Description:    Debian GNU/Linux oldstable-updates (sid)
> Release:        oldstable-updates
> Codename:       sid
>=20
>=20
>    * What outcome did you expect instead?
>=20
> An accurate report:
> :~$ cat /usr/lib/os-release
>=20
> PRETTY_NAME=3D"Debian GNU/Linux buster/sid"
> NAME=3D"Debian GNU/Linux"
> ID=3Ddebian
> HOME_URL=3D"https://www.debian.org/"
> SUPPORT_URL=3D"https://www.debian.org/support"
> BUG_REPORT_URL=3D"https://bugs.debian.org/"
>=20
>=20
> why lsb-release diplays sid while i am using buster?

lsb-release cannot _know_ that you're u sing buster and not sid, as the
/usr/lib/os-release file (as shipped by base-files) contains this "buster/
sid" string (you also find this in /etc/debian_version, which is what=20
lsb_release.py uses). That's specifically made to avoid having to have one=
=20
base-files package per suite, which would make base-files more of a special=
=20
package than it already is.

As, technically, a set of "unstable" packages could also be a valid set of=
=20
"testing" packages (5 days without bugs or uploads later, for instance),=20
it's impossible to guess from the files on the system whether it's running=
=20
"testing" or "unstable".

And finally, don't rely on lsb_release's output for anything non-stable;=20
it's bound to be unreliable, by construction. One should really rely on=20
feature-detection rather than version-matching.

Hereby closing as not-a-bug.

Cheers,
    OdyX