Dear Maintainer,

On Stretch, the "lsb_release -d" command shows the point release, like
this:

$ lsb_release -d
Description:    Debian GNU/Linux 9.10 (stretch)

On Buster, "lsb_release -d" does not show the point release:

$ lsb_release -d
Description:    Debian GNU/Linux 10 (buster)
$ cat /etc/debian_version
10.1

The expected output of "lsb_release -d" on Debian 10.1 would be:

Description:    Debian GNU/Linux 10.1 (buster)

Isn’t that a feature?

The x.y there was a remnant from Debian sarge times.

bye,
//mirabilos

Hello,
stretch I see only x.y, but it does seem new behaviour in buster to
only show x.

$ ansible '*' -i inventories/testing -a 'lsb_release -d' | grep ^Descr | sort -u
Description:    Debian GNU/Linux 10 (buster)
Description:    Debian GNU/Linux 8.11 (jessie)
Description:    Debian GNU/Linux 9.10 (stretch)

Cheers,
Andy

Hi,

This stems from lsb_release switching to reading the cross-distro
standard file, /usr/lib/os-release:

| $ cat /etc/debian_version
| 10.1
| $ cat /usr/lib/os-release
| PRETTY_NAME="Debian GNU/Linux 10 (buster)"
| NAME="Debian GNU/Linux"
| VERSION_ID="10"
| VERSION="10 (buster)"

So arguably base-files should be updating that file with point release
information, just as /etc/debian_version is. The spec [1] does not rule
that out, and other distributions do so:

| $ cat /etc/os-release
| NAME="Red Hat Enterprise Linux Server"
| VERSION="7.7 (Maipo)"
| VERSION_ID="7.7"
| PRETTY_NAME="Red Hat Enterprise Linux"

Please consider doing this urgently in stable, and possible even as a
stable update - it's having knock-on effects for us in several places
already, and I'm sure there will be other users with similar stories.

Severity upgraded because it causes an unexpected behaviour change in
lsb_release, but feel free to adjust.

1: https://www.freedesktop.org/software/systemd/man/os-release.html

Thanks,

reassign 939733 lsb-release
thanks

Therefore it was lsb_release who changed behaviour, not base-files.

Not ruling out != mandating it.

There was already a bug in base-files for this:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=931197

and it will be considered for bullseye, but the fact that os-release
does not change in Debian is clearly documented in the base-files
changelog:

 base-files (10.2) unstable; urgency=medium
 [...]
 Add also VERSION_ID and VERSION. (never expected to change)

So it may not be argued that this is a surprise from base-files side.

Reassigning again.

Thanks.

control: severity -1 +normal

[2019-09-10 10:21] Jonathan Wiltshire <jmw@tiger-computing.co.uk>

As pointed by maintainer of base-files, this format of
/usr/lib/os-release is with us for some time (just checked on stretch
box).

In theory, I can revert #914287, but is it good thing? Actually, I fail
to see the whole point of `lsb_release` command. You can't squash all
information in your /etc/apt/sources.list into two digits.

This said, I feel current behaviour more logical. LSB pretends to
provide cross-distributions interface, so reading /usr/lib/os-release
feels more natural than /etc/debian_release.

Hi.

Just to be sure: The proposed change would be *just* the VERSION_ID in
/etc/os-release, which at this moment would become "10.1" instead of "10".
Is this right?

I ask because we have a problem in lsb-release:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=939733

and changing /etc/os-release would be one possible way to fix the
problem in lsb-release.

I'm also Cc:ing the lsb-maintainers at bug #939733.

After this is clarified, I'll ask release managers about their opinion.

Thanks.

Hi.

I've asked the Release Managers about this here:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944351

If they say yes, I'll modify base-files accordingly (for Debian 10.2).

If they say no, please be ready to fix the bug in lsb-release as soon
as you can, by making an upload to proposed-updates (there is a point
release around the corner).

Thanks.

control: tags -1 +help

[2019-11-08 13:42] Santiago Vila <sanvila@unex.es>

I am losing context. We have at least following three files (oh, why all
this madness?):

 * /usr/lib/os-release
 * /etc/os-release
 * /etc/debian_version

So, in case of conflicts, what should override what?

BTW, help via NMU/Team upload is welcome.

AFAIK, lsb-release is already ignoring /etc/debian_version in buster,
which is the reason we have this problem.

We should either:

a) modify lsb-release so that it looks at /etc/debian_version again
(i.e. reverting the recent change)

or

b) As it has been suggested by you, fixing the problem in base-files
by including the minor version in /etc/os-release "somewhere".

I am ok with doing the change in base-files, because I believe it's
the best option in the long term.

I also believe that it would suffice to change VERSION_ID, but I need
confirmation for that.

My feeling is that Release Managers would welcome this change if it's
*limited* to VERSION_ID. Rationale: Major Release versions are integer
numbers (7, 8, 9, 10, etc), and we identify "buster" with "Debian 10",
without minor version, i.e. there should be no need
to change PRETTY_NAME or VERSION, only VERSION_ID.

So: Is this ok for you?

Thanks.

[2019-11-10 02:31] Santiago Vila <sanvila@unex.es>

Thank you for your patience.

Not exactly. We have following code, where get_os_release() reads
"/usr/lib/os-release", and guess_debian_release() uses several other
files, including "/etc/debian_version".

    lsbinfo = get_os_release()
    # OS is only used inside guess_debian_release anyway
    for key in ('ID', 'RELEASE', 'CODENAME', 'DESCRIPTION',):
        if key not in lsbinfo:
            distinfo = guess_debian_release()
            distinfo.update(lsbinfo)
            return distinfo
     else:
         return lsbinfo

So /etc/os-release overrides /etc/debian_version. Probably, we could
drop guess_debian_release() code though, since base-files are essential.

Yes, that is fine. As I just checked, `lsb_release -d` (as is in
Archives) will happily output anything I put into VERSION_ID variable of
/etc/os_release.

Santiago,

That is correct. Changing 'VERSION_ID=10' to 'VERSION_ID=10.1' in /etc/os-release is what I am asking.

---

Respectfully,

Sam Doran

Hi,

The request to fix this in buster was turned down after some discussion.
As such I'm not sure that this should be RC for lsb-release. Without
changes, this needs to be fixed at the right time in base-files anyways
(there's a bug open about that, severity minor).

In any case, I don't think this bug warrants to hold up the release,
especially because it won't be a regression anymore.

Paul

* Dmitry Bogatov <KAction@disroot.org> [2019-09-11 16:15]:

That appears to have failed. Trying again, as a service :-)