

Introducing /etc/os-release - End to distribution specific release files - sagarun
http://0pointer.de/blog/projects/os-release.html

======
rwmj
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.

[1]
[https://github.com/libguestfs/libguestfs/blob/84a4160fd30c46...](https://github.com/libguestfs/libguestfs/blob/84a4160fd30c46575b93f87f6ffc7cc556b0af93/src/inspect_fs_unix.c#L51)

~~~
astrosi
And if not then this xkcd comes to mind: <http://xkcd.com/927/>

~~~
rwmj
Yes, and this too: <http://www.jwz.org/doc/cadt.html>

------
nailer
Author complains 'lsb_release -d', the standard from ten years ago, isn't
always there.

Proposes alternative to fix this, by changing to a new system , which will
solve this problem, once it's always there.

~~~
ruediger
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

~~~
nailer
> It's an optional package in many distributions

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.

~~~
devicenull
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?

~~~
nailer
> 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?

(assuming redhat-lsb is the package that owns $(which lsb_release) )

No. Red Hat should fix that.

------
pilif
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...](http://www.freedesktop.org/software/systemd/man/os-
release.html)) 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)

~~~
TimMontague
There is already a bug report for your second issue:

<https://bugs.freedesktop.org/show_bug.cgi?id=46021>

------
waitwhat
_recently the majority of the big distributions adopted /etc/os-release and
many small ones did, too[2]_

 _[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?

~~~
ars
Debian is quite notably missing from that list.

<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.

------
beza1e1
He complains about the lsb_release executable, but why not use the /etc/lsb-
release file directly?

<http://linux.die.net/man/1/lsb_release>

~~~
russss
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.

~~~
rwmj
This isn't completely true. lsb-release contains everything that is in os-
release, including the version of the distro in a neutral format.

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.

~~~
ars
As far as I can tell Debian does not have an /etc/lsb-release _file_. Rather
they have an lsb-release _program_ that outputs the necessary info.

------
unwind
I loved this, from the FAQ:

 _Why didn't you call this file /etc/bikeshed instead?_

Nothing like good self-referential, recursive, meta humor. :)

------
otterley
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.

------
unimpressive
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.

------
glabifrons
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.

------
pwg
XKCD reference: <http://xkcd.com/927/>

------
devicenull
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

------
nodata
Does anyone have examples of these extra fields he is talking about adding to
this new file?

~~~
noselasd
[http://www.freedesktop.org/software/systemd/man/os-
release.h...](http://www.freedesktop.org/software/systemd/man/os-release.html)

