Bug#703677: lsb-release is not derivative friendly
Package: lsb-release Version: 4.1+Debian9 Severity: important A Debian derivative is advised to fork base-files and to update the information there so that it can be properly distinguished from Debian. That's what we did for Kali and yet we have reportbug sending bug reports to Debian: $ reportbug apt [...] Will send report to Debian (per lsb_release). So I looked at lsb-release's output: $ lsb_release -a No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux Kali Linux 1.0 Release:Kali Linux 1.0 Codename: n/a It's just wrong to return Debian as distributor ID when we have this: ┏(kali-amd64) x230-buxy:~ ┗(524)$ cat /etc/os-release PRETTY_NAME=Kali GNU/Linux 1.0 NAME=Kali GNU/Linux ID=kali VERSION=1.0 VERSION_ID=1.0 ID_LIKE=debian ANSI_COLOR=1;31 HOME_URL=http://www.kali.org/; SUPPORT_URL=http://forums.kali.org/; BUG_REPORT_URL=http://bugs.kali.org/; ┏(kali-amd64) x230-buxy:~ ┗(525)$ cat /etc/dpkg/origins/default Vendor: Kali Vendor-URL: http://www.kali.org/ Parent: debian Bugs: http://bugs.kali.org ┏(kali-amd64) x230-buxy:~ ┗(526)$ cat /etc/debian_version Kali Linux 1.0 So please update lsb_release's logic to use: 1/ /etc/lsb-release if it exists (it doesn't usually) 2/ /etc/os-release if it exists 3/ /etc/dpkg/origins/default if none of the above exist 4/ some wild guess based on APT otherwise Please let me know if you need help. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703677: lsb-release is not derivative friendly
Control: tags -1 +confirmed
Hi Raphaël, and thanks for your bugreport,
Le vendredi, 22 mars 2013 09.11:20, Raphaël Hertzog a écrit :
A Debian derivative is advised to fork base-files and to update the
information there so that it can be properly distinguished from Debian.
That's what we did for Kali and yet we have reportbug sending bug
reports to Debian:
$ reportbug apt
[...]
Will send report to Debian (per lsb_release).
So I looked at lsb-release's output:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux Kali Linux 1.0
Release: Kali Linux 1.0
Codename: n/a
You're saying that the wrong line is Distributor ID (the output of
lsb_release -i), right ?
It's just wrong to return Debian as distributor ID when we have
this:
(…)
Agreed.
So please update lsb_release's logic to use:
1/ /etc/lsb-release if it exists (it doesn't usually)
2/ /etc/os-release if it exists
3/ /etc/dpkg/origins/default if none of the above exist
4/ some wild guess based on APT otherwise
Please let me know if you need help.
From what I can see in the code, the current logic is the following:
1/ /etc/lsb-release - get_lsb_information()
2/ 'Debian' - guess_debian_release()
Indeed, guess_debian_release has:
distinfo = {'ID' : 'Debian'}
That said, /etc/os-release is not used anywhere in lsb(-release) yet, so I'm
open to implement 3/ /etc/dpkg/origins/default parsing for now, but would
rather avoid parsing os-release only for ID (but help is welcome). Also, I'm
yet to see an advantage for apt parsing where dpkg origins are already
supposed to provide the correct information (as derivatives are supposed to
fork base-files anyway).
I'll see if I can get a patch for 3/ /etc/dpkg/origins/default parsing soon,
but I welcome help there too.
Cheers,
OdyX
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#703677: lsb-release is not derivative friendly
Hi, On Fri, 22 Mar 2013, Didier 'OdyX' Raboud wrote: No LSB modules are available. Distributor ID: Debian Description:Debian GNU/Linux Kali Linux 1.0 Release:Kali Linux 1.0 Codename: n/a You're saying that the wrong line is Distributor ID (the output of lsb_release -i), right ? Yes, but description looks wrong too. It could use the PRETTY_NAME from /etc/os-release instead of making up something weird. 3/ /etc/dpkg/origins/default if none of the above exist 4/ some wild guess based on APT otherwise Please let me know if you need help. From what I can see in the code, the current logic is the following: 1/ /etc/lsb-release - get_lsb_information() 2/ 'Debian' - guess_debian_release() Yes. That said, /etc/os-release is not used anywhere in lsb(-release) yet, so I'm /etc/os-release has been promoted as a vendor-neutral file on which we should standardize. I believe it would be a good idea to use it. open to implement 3/ /etc/dpkg/origins/default parsing for now, but would rather avoid parsing os-release only for ID (but help is welcome). Also, I'm yet to see an advantage for apt parsing where dpkg origins are already supposed to provide the correct information (as derivatives are supposed to fork base-files anyway). I also don't see the value on the APT parsing but I saw code for this so I left it in my list. I'll see if I can get a patch for 3/ /etc/dpkg/origins/default parsing soon, but I welcome help there too. reportbug has some python code parsing that file in /usr/share/pyshared/reportbug/debbugs.py Cheers, -- Raphaël Hertzog ◈ Debian Developer Get the Debian Administrator's Handbook: → http://debian-handbook.info/get/ -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
