lsb_release useless on NixOS
Closed this issue · 23 comments
We have the lsb-release package in nixpkgs, but if you run it on NixOS, you get:
LSB Version: n/a
Distributor ID: n/a
Description: (none)
Release: n/a
Codename: n/a
It seems like we need a file in /etc/lsb_release for the tool to find. My inclination would be to make a NixOS module that just injects sensible values into that file and to include it unconditionally. Am I missing anything obvious there?
Edit: or we could patch it somehow to just read /etc/os-release, which seems like a better path forward, but less standard.
It's worth noting that having (maybe it needs to be a non-symlink though?) /etc/lsb_release makes grub-mkconfig of other distros try to add NixOS configurations to their grub configurations, which is probably not desirable: #7406 (comment)
What do you think about this?
--- a/lsb_release
+++ b/lsb_release
@@ -43,7 +43,7 @@
# Defines the data files
INFO_ROOT="/etc" # directory of config files
-INFO_LSB_FILE="lsb-release" # where to get LSB version
+INFO_LSB_FILE="os-release" # where to get LSB version
INFO_DISTRIB_SUFFIX="release" # <distrib>-<suffix>
ALTERNATE_DISTRIB_FILE="/etc/debian_version" # for Debian [based distrib]
ALTERNATE_DISTRIB_NAME="Debian" # "
@@ -167,6 +167,10 @@
then
# should init at least LSB_VERSION
. "$INFO_ROOT/$INFO_LSB_FILE"
+ DISTRIB_ID=$ID
+ DISTRIB_DESCRIPTION=$PRETTY_NAME
+ DISTRIB_RELEASE=$VERSION_ID
+ DISTRIB_CODENAME=$(echo $VERSION | cut -d\( -f2 | cut -d\) -f1)
fi
[ -z "$LSB_VERSION" ] && LSB_VERSION=$MSG_NA
}Only LSB_VERSION is missing. It's supposed to be something like
:core-4.1-amd64:core-4.1-noarch:cxx-4.1-amd64:cxx-4.1-noarch:desktop-4.1-amd64:desktop-4.1-noarch:languages-4.1-amd64:languages-4.1-noarch:printing-4.1-amd64:printing-4.1-noarch
I have no idea what its meaning is and I couldn't find more information about it.
On Ubuntu the path is /etc/lsb-release and it has a different content than /etc/os-release.
/etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=16.04
DISTRIB_CODENAME=xenial
DISTRIB_DESCRIPTION="Ubuntu 16.04.2 LTS"
/etc/os-release
NAME="Ubuntu"
VERSION="16.04.2 LTS (Xenial Xerus)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 16.04.2 LTS"
VERSION_ID="16.04"
HOME_URL="http://www.ubuntu.com/"
SUPPORT_URL="http://help.ubuntu.com/"
BUG_REPORT_URL="http://bugs.launchpad.net/ubuntu/"
VERSION_CODENAME=xenial
UBUNTU_CODENAME=xenial
I installed the lsb-release package on NixOS 16.09 and created /etc/lsb-release, but still get:
LSB Version: n/a
I also renamed /etc/lsb-release to /etc/lsb_release but still same output.
Should we also include this package by default that people can use it to see on what type of system they are?
I installed the lsb-release package on NixOS 16.09 and created /etc/lsb-release, but still get:
Seems like the version in nixpkgs (currently 1.4 from 2001-01-04 :D) is outdated and still from sourceforge.
I think the most recent version is 4.1 (repo-link) or 5.0 (news-link).
We should probably upgrade the tool first and then test it again.
Edit/Update: Seems like the Debian guys have their own version, Arch is using 1.4 with the correct upstream URL, Fedora and Red-Hat (etc.) use redhat-lsb - The current situation seems to be pretty "interesting" 😄
Update2: The most recent version in the upstream repository (Bazaar) is from 2004-06-30 which probably doesn't make much of a difference (either there isn't anything to fix or they're prioritising the specification, tests, etc.). Essentially it's only a simple Bash-Script (or a Python script in case of the Debian repo).
@davidak It's working if you use pass -a as an argument (IIRC that's different on the Debian version).
We could simply change the file name at line 46 (INFO_LSB_FILE variable) if we want to use /etc/os-release instead (and a symbolic link should work as well). The Bash script simply sources that file and then uses the shell variables.
Should we also include this package by default that people can use it to see on what type of system they are?
👍 - Sounds like a good idea and AFAIK most (nearly all?) Linux distributions include it by default (Gentoo is the only exception I remember).
We could also simply write our own version as well.
Or we could rewrite nixos-version.sh accordingly to the specification (or at least try to make it as compatible as possibly) and use it for both lsb_release and nixos-version (just some thoughts 😄).
We could also simply write our own version as well.
Why? There are more important things to do. Just replace with the most official version and get it to work.
if we want to use /etc/os-release instead
is there any advantage to not use the common path? some scripts may depend on that path or people just cat it
The LSB Download page is temporarily down, and will be made available shortly.
Time to have an IPFS mirror of all our sources. So wait if it comes up again the next days, maybe ask, or else use the 4.1 from bzw repo.
When lsb_release works we can propose deleting nixos-version and just refer to it in the issue template and manual.
Time to have an IPFS mirror of all our sources.
We mirror most sources already (but not on IPFS).
I asked when the LSB Download page will be up again.
the work is currently in process
So we can wait some days until it is available again.
Can we get consent on how to proceed until then?
Can we get consent on how to proceed until then?
We could try but then I'd recommend asking at #nixos, nix-dev or mentioning some devs. Also a quick reminder that branch-off is in 5 days (28. February).
We could also simply write our own version as well.
Why? There are more important things to do. Just replace with the most official version and get it to work.
There are "always" more important things to do... (and I would even volunteer to write that version if necessary).
The question is whether it would help or not.
https://gist.github.com/skx/1f9e5240856c5976193a - An example for a simple Bash implementation (only 135 lines of code).
The advantage of writing our own version would be that we could introduce an additional "--hash|--revision" option which would make if compatible with nixos-version. And since nixos-version already exists as a Bash script inside the nixpkgs repo we could simply rewrite/extend it accordingly.
Also that way we could ignore the actual LSB stuff (I'm not aware of a discussion whether we want to follow the actual specification or not).
But there are obviously disadvantages as well.
is there any advantage to not use the common path? some scripts may depend on that path or people just
catit
When
lsb_releaseworks we can propose deletingnixos-versionand just refer to it in the issue template and manual.
Especially deleting nixos-version would require a post to nix-dev and a note in the release notes. This could potentially break a lot of custom scripts which is why I'd try to avoid that. And we would have to properly replace all references (manual, modules, tests, the issue template, ... - git grep nixos-version).
Anyway imho it's already a bit too late for 17.3 but could we add a milestone for 17.9?
Note that nix packages have to break LSB, by design, so I don't think we should claim any LSB version at all.
Note that nix packages have to break LSB, by design
@vcunat thanks for clarifying. it's not about beeing LSB compliant, just about having the lsb_release program so people that wants to know on what system they are get that information, in a convenient way. i think using the official script and throwing the information in a textfile would be the easiest option to achieve this. but maybe we should avoid any "lsb" in NixOS...
The advantage of writing our own version would be that we could introduce an additional "--hash|--revision" option which would make if compatible with nixos-version. And since nixos-version already exists as a Bash script inside the nixpkgs repo we could simply rewrite/extend it accordingly.
@primeos thats a point, so why not if you would like to do that.
Especially deleting nixos-version would require a post to nix-dev and a note in the release notes. This could potentially break a lot of custom scripts which is why I'd try to avoid that. And we would have to properly replace all references (manual, modules, tests, the issue template, ... - git grep nixos-version).
sure. when we have this issue done, we could propose marking nixos-version as deprecated in release notes etc and delete every reference. then delete the actual command in the next release (17.09)
I meant just the contents of that line, which we might best leave as it is:
LSB Version: n/a
I didn't mean that it's whole useless or anything similar.
Isn't lsb_release more or less deprecated now that we have /etc/os-release? (Why bother with it?)
@bjornfor i have sometimes the case that i get a ssh login and have to move a website from a server to our server. i'm interested what os is running. i use cat /etc/issue what NixOS don't have or lsb_release -a what works at least on debian based systems. on NixOS i currently get no information with this methods.
@davidak: But what if you run "cat /etc/os-release"? That works on all(?) modern distros, right?
/etc/os-release does exist on all the ones I've tried, but I don't think anyone's explicitly deprecated lsb_release as a result, so tools and humans still use it a fair amount.
@bjornfor @copumpkin I agree that lsb_release is a legacy tool but like @copumpkin said tools and humans probably still use it a fair amount. Do you think we should include lsb_release by default or not? And if you have time for it I'd be interested what you think of #23175 (it basically extends the nixos-version Bash script so that we could use it for lsb_release as well).
I have no strong opinion.
whether we make lsb_release do something in NixOS, or not, but it should definitely work by default in an FHS env. Which it currently doesn't
My use case was to play around with the chromium source tree. The tools to do so (repo, gclient, hooks) are complicated, chromium-specific and prone to a high rate of change, thus good candidates to be worked within an FHS env.
lsb_release is one of the tools, that chromium expects to be functional