Because not all Linux distributions follow Linux Standard Base. It would be silly for (to use an example) Arch to have a lsb-release file when it's very method is anything but LSB. So os-release gives a unified file regardless of the distro methodology. In fact this file could easily be extended beyond Linux to any Unix-like OS - which lsb-release would be less practical for.
>To address this, the standard does not dictate what package format the software system must use for its own packages, merely that RPM must be supported to allow packages from third-party distributors to be installed on a conforming system.
Well yeah, that's how Debian gets around the issue. However Arch doesn't have an RPM converter in it's standard set up (or if there is, I'm unaware of it).
Personally I massively prefer Arch's package manager to anything I've seen on any RPM-based distro and it seems pretty pointless in having an "alien"-like RPM converter for Arch given how exhaustive Pacman + AUR is. However the point remains that Arch would fail LSB due to this.
Well you said that Arch would fail LSB because it didn't have a converter, which seems strange if - as my link appears to show - it is capable of using RPM natively. That is why do they need to convert .rpm packages if they can run RPM and install them direct? Not that I'm saying there wouldn't be any work to do but the fact that people are already using .rpm via RPM (the binary program) would appear to show it's not a huge obstacle.
To me says that the distro can use any package format it likes ("The implementation itself may use a different packaging format for its own packages") as long as it can handle .rpm packages ("Implementations shall provide a mechanism for installing applications in this [RPM] packaging format"). So if Arch shipped RPM it would appear [superficially] to meet the requirements.
As mentioned in that man page, the /etc/lsb-release file only contains details on what version of the LSB the distribution conforms to (if the distribution isn't LSB-compliant, the file shouldn't exist). It doesn't have the version of the distribution itself, which lsb_release finds in distribution-specific locations.
On the one hand the idea is good. In libguestfs we go to huge lengths to deal with the release files of many different Linux and BSD distributions[1].
On the other hand, when was this discussed? Are all the Linux distros and BSD on board? OS X? Windows? (I'm serious)
/etc/os-release has all the problems of /etc/lsb-release, but even fewer people will use it (if you count distro numbers rather than users, hardly anyone is using lsb-release).
This file could have been a lot more useful if it had been discussed with people who might consume it. As it is, we'll be parsing this as a fallback, but continue using distro-specific release files.
I think it's really only missing Debian and Ubuntu to cover the "big distributions", so while "majority" might be a strong word, it does seem to have about half of them.
What I want to see (Or make) is a system that's extensible enough to be made compatible with current package managers simply through extension modules. (Something like VLC levels of customization.) But that has a native package format so that most software providers can expect to find this skeleton-package-manager on the system.
Though I'm not even sure if thats really possible.
I think he made a point saying that lsb_release needs to spawn a process to get the result, while /etc/os-release it's just opening a simple text file and parsing it.
That lsb_release is "an optional package in many distributions" is only a minor complain:
> There's already the lsb_release tool for this, why don't you just use that? Well, it's a very strange interface: a shell script you have to invoke (and hence spawn asynchronously from your C code), and it's not written to be extensible. It's an optional package in many distributions, and nothing we'd be happy to invoke as part of early boot in order to show a welcome message. (In times with sub-second userspace boot times we really don't want to invoke a huge shell script for a triviality like showing the welcome message). The lsb_release tool to us appears to be an attempt of abstracting distribution checks, where standardization of distribution checks is needed. It's simply a badly designed interface. In our opinion, it has its use as an interface to determine the LSB version itself, but not for checking the distribution or version.
And I guess distributions are far more reluctant to install a shell script than adding a file to /etc
If only Linux packaging system had some kind of dependency system. That way systemd and other LSB needing packages could require lsb. You could even have some kind of automated packaging tool, or perhaps modify yellowdog updater, to fetch those dependencies automatically.
Attempting to install redhat-lsb on CentOS 6 drags in:
alsa
cups
ghostscript
gstreamer
pixman
qt
fonts
poppler
and more (102 packages in total!)
Now, this is on a server, so I have no use for audio, printing, streaming, pdf creation, nor any sort of GUI components. Do you really think it's reasonable that all that needs to be installed just to tell me what version of the operating system is running?
Nice summary. And when people ask me why Linux is the way it is, I point at an example like this one and say 'This is why.'
It would be 'hard' to make lsb_release do what they want (either the maintainers reject their pull requests, or perhaps outright reject their ideas) and its 'easy' to create a new way to do it.
Hence every copy of Linux has some percentage of the 'boring' stuff which works the same everywhere, and the 'interesting' stuff works differently between major distros,
Things are 'boring' if nobody cares about them.
Things are 'interesting' if they are user facing, and especially self contained enough that the entire feature can be shipped in one moderate sized patch.
While I see no problem with having a centralized file to get OS information from, I do have two issues with the file that's proposed here:
One is that I believe it shouldn't be in /etc which is generally used for configuration data, not for static distribution info. I'd put it somewhere in /usr/lib or /usr/share.
Second, I think that the linked documentation (http://www.freedesktop.org/software/systemd/man/os-release.h...) is incomplete in that it doesn't specify quoting behavior: The file doesn't say anything about when or if at all values need to be quoted but the has quotes on some string values (but not all) in the example.
Are the quotes part of the value and thus should be displayed? Or are quotes needed for values with spaces in them?
Yes. I'm nit-picking, but IF you have to start off a new standard, please be sufficiently precise in order to reduce the need for somebody else having to do the same a few years down the road.
Other possible questions: Do custom keys need to be uppercase? Can they contain spaces themselves? ANSI_COLOR is a nice idea, can we also have a background color? Are spaces allowed in front and after the = sign? Are spaces in front and after the = sign part of the key or value? Or are they to be ignored?
Maybe use a standard format like YAML or JSON or (god forbid) XML which already has things like this covered.
Yes. This is all really small stuff, but in the end it's this unspecified small stuff that causes everybody to implement their solution differently which in turn makes writing a parser needlessly hard (or even impossible if there are conflicting interpretations)
Relying on some hint system (whatever it might be) to infer how the system is configured is a bad practice; it could lead to faulty assumptions because the administrator is free to change anything post hoc.
Scripts that care where things are should do their own investigation and determine the locations of files and how daemons are configured themselves. In other words, use the primary sources.
It's interesting that someone supposedly from Red Hat decided to drop support for anything without this. I just checked on a CentOS 6 box (closest thing I have) and it doesn't have /etc/os-release
Those who cannot learn from history are doomed to repeat it.
I've never understood why most major Linux distribution creators chose to come up with their own /etc/*-release files. Why make it distribution-specific at all?
In all seriousness, what's wrong with the /etc/release file (Solaris) that predates Linux?
The name is obvious, terse, and easy to remember.
41 comments
[ 5.2 ms ] story [ 101 ms ] threadhttp://linux.die.net/man/1/lsb_release
I don't see a problem.
Personally I massively prefer Arch's package manager to anything I've seen on any RPM-based distro and it seems pretty pointless in having an "alien"-like RPM converter for Arch given how exhaustive Pacman + AUR is. However the point remains that Arch would fail LSB due to this.
Doesn't it need to just run rpm binary itself - http://aur.archlinux.org/packages.php?ID=16857 kinda suggests that's more than feasible.
It's great that it's available in AUR, but it wouldn't be enough to pass LSB - which is the /entire/ point of this tangent.
http://refspecs.linuxbase.org/LSB_3.1.0/LSB-Core-generic/LSB...
To me says that the distro can use any package format it likes ("The implementation itself may use a different packaging format for its own packages") as long as it can handle .rpm packages ("Implementations shall provide a mechanism for installing applications in this [RPM] packaging format"). So if Arch shipped RPM it would appear [superficially] to meet the requirements.
However I agree with you that lsb-release is not much used, and in some distros is only present when some huge X-dependent LSB package is installed.
But hey, we could fix LSB! Instead of, you know, making up something new that will be as little used as lsb-release.
On the other hand, when was this discussed? Are all the Linux distros and BSD on board? OS X? Windows? (I'm serious)
/etc/os-release has all the problems of /etc/lsb-release, but even fewer people will use it (if you count distro numbers rather than users, hardly anyone is using lsb-release).
This file could have been a lot more useful if it had been discussed with people who might consume it. As it is, we'll be parsing this as a fallback, but continue using distro-specific release files.
[1] https://github.com/libguestfs/libguestfs/blob/84a4160fd30c46...
[2] To our knowledge at least OpenSUSE, Fedora, ArchLinux, Angstrom, Frugalware have adopted this.
So "OpenSUSE, Fedora, ArchLinux, Angstrom, Frugalware" is "the majority of the big distributions" now?
http://bugs.debian.org/659853
It doesn't have /etc/lsb-release either.
http://bugs.debian.org/444678
Instead the lsb-release program apparently simply outputs the necessary values without using a configuration file.
I'm guessing the debian version of systemd just patches it to handle debian, and not make it autoconfigure each time from a configuration file.
The author of this blog post, Lennart Poettering, apparently works for Red Hat. Even Hat Enterprise Linux is missing from the list. As is CentOS.
There also seems to be a bug report for it on Debian: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659891
One thing I feel people might be missing is that /etc/os-release could be applicable to Mac OS and the BSDs, making it widely applicable.
Though I'm not even sure if thats really possible.
Proposes alternative to fix this, by changing to a new system , which will solve this problem, once it's always there.
> There's already the lsb_release tool for this, why don't you just use that? Well, it's a very strange interface: a shell script you have to invoke (and hence spawn asynchronously from your C code), and it's not written to be extensible. It's an optional package in many distributions, and nothing we'd be happy to invoke as part of early boot in order to show a welcome message. (In times with sub-second userspace boot times we really don't want to invoke a huge shell script for a triviality like showing the welcome message). The lsb_release tool to us appears to be an attempt of abstracting distribution checks, where standardization of distribution checks is needed. It's simply a badly designed interface. In our opinion, it has its use as an interface to determine the LSB version itself, but not for checking the distribution or version.
And I guess distributions are far more reluctant to install a shell script than adding a file to /etc
If only Linux packaging system had some kind of dependency system. That way systemd and other LSB needing packages could require lsb. You could even have some kind of automated packaging tool, or perhaps modify yellowdog updater, to fetch those dependencies automatically.
(assuming redhat-lsb is the package that owns $(which lsb_release) )
No. Red Hat should fix that.
Aye, and if you don't implement it you are "working towards the further balkanization of the Linux landscape".
Is this arrogance? Dictatorship? Am I being too sensitive? Whatever it is, it does not strike me as an effective way to get people on board.
Tell us why it is better, not that we are wrong if we don't do it.
It would be 'hard' to make lsb_release do what they want (either the maintainers reject their pull requests, or perhaps outright reject their ideas) and its 'easy' to create a new way to do it.
Hence every copy of Linux has some percentage of the 'boring' stuff which works the same everywhere, and the 'interesting' stuff works differently between major distros,
Things are 'boring' if nobody cares about them.
Things are 'interesting' if they are user facing, and especially self contained enough that the entire feature can be shipped in one moderate sized patch.
Why didn't you call this file /etc/bikeshed instead?
Nothing like good self-referential, recursive, meta humor. :)
One is that I believe it shouldn't be in /etc which is generally used for configuration data, not for static distribution info. I'd put it somewhere in /usr/lib or /usr/share.
Second, I think that the linked documentation (http://www.freedesktop.org/software/systemd/man/os-release.h...) is incomplete in that it doesn't specify quoting behavior: The file doesn't say anything about when or if at all values need to be quoted but the has quotes on some string values (but not all) in the example.
Are the quotes part of the value and thus should be displayed? Or are quotes needed for values with spaces in them?
Yes. I'm nit-picking, but IF you have to start off a new standard, please be sufficiently precise in order to reduce the need for somebody else having to do the same a few years down the road.
Other possible questions: Do custom keys need to be uppercase? Can they contain spaces themselves? ANSI_COLOR is a nice idea, can we also have a background color? Are spaces allowed in front and after the = sign? Are spaces in front and after the = sign part of the key or value? Or are they to be ignored?
Maybe use a standard format like YAML or JSON or (god forbid) XML which already has things like this covered.
Yes. This is all really small stuff, but in the end it's this unspecified small stuff that causes everybody to implement their solution differently which in turn makes writing a parser needlessly hard (or even impossible if there are conflicting interpretations)
https://bugs.freedesktop.org/show_bug.cgi?id=46021
Unix shells have very well defined specifications.
Scripts that care where things are should do their own investigation and determine the locations of files and how daemons are configured themselves. In other words, use the primary sources.
I've never understood why most major Linux distribution creators chose to come up with their own /etc/*-release files. Why make it distribution-specific at all?
In all seriousness, what's wrong with the /etc/release file (Solaris) that predates Linux? The name is obvious, terse, and easy to remember.