Bug#866778: marked as done (lsb-release: lsb_release --all displays inconsistent information)
Your message dated Wed, 05 Jul 2017 21:40:40 +0200
with message-id <[hidden email]>
and subject line Re: Bug#866778: lsb-release: lsb_release --all displays inconsistent information
has caused the Debian Bug report #866778,
regarding lsb-release: lsb_release --all displays inconsistent information
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [hidden email] immediately.)
Kernel: Linux 4.9.0-3-amd64 (SMP w/2 CPU cores)
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8), LANGUAGE=fr_FR.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages lsb-release depends on:
ii distro-info-data 0.36
ii python3 3.5.3-1
Versions of packages lsb-release recommends:
ii apt 1.4.6
Versions of packages lsb-release suggests:
pn lsb <none>
-- no debconf information
Control: tags -1 +wontfix
Le samedi, 1 juillet 2017, 18.38:28 h CEST GT a écrit :
> * What led up to the situation?
> use of the command lsb_release --all
> :~$ lsb_release --all
> No LSB modules are available.
> Distributor ID: Debian
> Description: Debian GNU/Linux oldstable-updates (sid)
> Release: oldstable-updates
> Codename: sid
> * What outcome did you expect instead?
> An accurate report:
> :~$ cat /usr/lib/os-release
> PRETTY_NAME="Debian GNU/Linux buster/sid"
> NAME="Debian GNU/Linux"
> 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
lsb_release.py uses). That's specifically made to avoid having to have one
base-files package per suite, which would make base-files more of a special
package than it already is.
As, technically, a set of "unstable" packages could also be a valid set of
"testing" packages (5 days without bugs or uploads later, for instance),
it's impossible to guess from the files on the system whether it's running
"testing" or "unstable".
And finally, don't rely on lsb_release's output for anything non-stable;
it's bound to be unreliable, by construction. One should really rely on
feature-detection rather than version-matching.