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
Reply to: