On Wed, 2 Jan 2019, Didier 'OdyX' Raboud wrote: > /etc/lsb-release is a Debian-specific file, that the LSB spec doesn't > mention. > Only the `lsb-release` command should be used:
Yes, which is what the rules files are using. We just need to be able to override the normal result for sid chroots. > DISTRIB_RELEASE goes in `lsb_release -r`, and is taken from > `/etc/debian_version`, which is in /etc, so is overridable. > > DISTRIB_CODENAME goes in `lsb_release -c` and is also taken from > `/etc/debian_version`, but when this contains "buster/sid", it falls back on > parsing `apt-cache policy`. Hm, perhaps, but apt-cache output is tricky if multiple distributions are in use (e.g. ports architectures have unreleased in addition). > When built in/for Debian, packages: > * should really not rely on the output of `lsb_release`, but I doubt that. This is a _really_ useful tool, and having only this one makes it easy to have consistent behaviour for all such packages, if lsb_release plays nice. (Which is what I’m asking for.) The packaging of OpenJDK is an in-tree example using this. I’m similarily using this for a company-local package. > * really *must not* depend on `/etc/lsb-release` to second-guess `lsb- > release`. We don’t do that, we just run lsb_release with various parameters. > That said, if you still think lsb_release should allow overrides from that > Debian-specific file, please file another bug, ideally with a patch that > lets > `lsb_release` be noisy about its usage. I do still think so, not sure about the wording, but I’ll probably file the bug once I get to that. (I only just saw this during a dist-upgrade, and am working with other fallout at the moment.) Thanks, //mirabilos -- 15:41⎜<Lo-lan-do:#fusionforge> Somebody write a testsuite for helloworld :-)
