Discussion:
Bug#939733: lsb-release: lsb_release does not show point release on Debian 10.1
(too old to reply)
Markku Leiniö
2019-09-08 08:50:01 UTC
Permalink
Package: lsb-release
Version: 10.2019051400
Severity: normal

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)


-- Package-specific info:
lsb_release output
-*- -*- -*- -*- -*-
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
-*- -*- -*- -*- -*-
Apt policy
-*- -*- -*- -*- -*-
Package files:
100 /var/lib/dpkg/status
release a=now
500 http://repo.zabbix.com/zabbix/4.0/debian buster/main amd64 Packages
release o=Zabbix,n=buster,l=zabbix,c=main,b=amd64
origin repo.zabbix.com
500 https://download.docker.com/linux/debian buster/stable amd64 Packages
release o=Docker,a=buster,l=Docker CE,c=stable,b=amd64
origin download.docker.com
500 http://www.nic.funet.fi/debian buster-updates/main amd64 Packages
release o=Debian,a=stable-updates,n=buster-updates,l=Debian,c=main,b=amd64
origin www.nic.funet.fi
500 http://security.debian.org/debian-security buster/updates/main amd64 Packages
release v=10,o=Debian,a=stable,n=buster,l=Debian-Security,c=main,b=amd64
origin security.debian.org
500 http://www.nic.funet.fi/debian buster/main amd64 Packages
release v=10.1,o=Debian,a=stable,n=buster,l=Debian,c=main,b=amd64
origin www.nic.funet.fi
Pinned packages:
-*- -*- -*- -*- -*-
sources.list
-*- -*- -*- -*- -*-
deb http://www.nic.funet.fi/debian/ buster main
deb-src http://www.nic.funet.fi/debian/ buster main
deb http://security.debian.org/debian-security buster/updates main
deb-src http://security.debian.org/debian-security buster/updates main
deb http://www.nic.funet.fi/debian/ buster-updates main
deb-src http://www.nic.funet.fi/debian/ buster-updates main
deb [arch=amd64] https://download.docker.com/linux/debian buster stable
-*- -*- -*- -*- -*-
/etc/lsb_release
-*- -*- -*- -*- -*-
- none

-- System Information:
Debian Release: 10.1
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.19.0-6-amd64 (SMP w/2 CPU cores)
Kernel taint flags: TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lsb-release depends on:
ii distro-info-data 0.41
ii python3 3.7.3-1

Versions of packages lsb-release recommends:
ii apt 1.8.2

Versions of packages lsb-release suggests:
pn lsb <none>

-- no debconf information
Thorsten Glaser
2019-09-08 15:30:02 UTC
Permalink
Post by Markku Leiniö
=20
$ lsb_release -d
Description: Debian GNU/Linux 10 (buster)
Isn=E2=80=99t that a feature?

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

bye,
//mirabilos
--=20
tarent solutions GmbH
Rochusstra=C3=9Fe 2-4, D-53123 Bonn =E2=80=A2 http://www.tarent.de/
Tel: +49 228 54881-393 =E2=80=A2 Fax: +49 228 54881-235
HRB 5168 (AG Bonn) =E2=80=A2 USt-ID (VAT): DE122264941
Gesch=C3=A4ftsf=C3=BChrer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Ale=
xander Steeg
Andy Smith
2019-09-09 13:20:02 UTC
Permalink
Hello,
Post by Markku Leiniö
$ lsb_release -d
Description: Debian GNU/Linux 10 (buster)
Isn’t that a feature?
The x.y there was a remnant from Debian sarge times.
Up until squeeze I have seen it show x.y.z, then from wheezy to
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
Santiago Vila
2019-11-08 12:50:01 UTC
Permalink
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.
Dmitry Bogatov
2019-11-10 01:20:02 UTC
Permalink
control: tags -1 +help
Post by Santiago Vila
Hi.
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).
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.
--
Note, that I send and fetch email in batch, once in a few days.
Please, mention in body of your reply when you add or remove recepients.
Santiago Vila
2019-11-10 01:40:01 UTC
Permalink
Post by Dmitry Bogatov
control: tags -1 +help
Post by Santiago Vila
Hi.
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).
I am losing context. We have at least following three files (oh, why all
* /usr/lib/os-release
* /etc/os-release
* /etc/debian_version
So, in case of conflicts, what should override what?
Please note that /usr/lib/os-release and /etc/os-release are the same file.

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.

Loading...