Use /etc/os-release instead of /etc/issue to determine the distro

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run inxi with a non-standard /etc/issue

What is the expected output? What do you see instead?
The distro field should show the current distro, instead it shows "/etc/ 
corrupted, use -% to override"

What version of the product are you using? On what operating system?
1.8.13 on Arch GNU/Linux

Instead of just parsing /etc/issue which many people edit themselves to get a 
nice bootup message, inxi should use /etc/os-release and possibly /etc/issue as 
a fallback for older distros.

Original issue reported on code.google.com by ne.tet...@gmail.com on 3 Jul 2012 at 2:36

[GoogleCodeExporter]

in general when posting issues, you should post the relevant data, in this 
case, the contents of /etc/os-release, which as far as I know is only used by 
arch, and it's new, ie, this is not a defect, this is a changed file in the 
source distro.

However someone else showed that file's contents from Arch so I have that.

To be clear, this is not a replacement for /etc/issue, this is a 
distro-specific id file which simply has a new format. Clearly Arch should be 
using the standardized /etc/lsb-release file but opted instead to invent a new 
format.

This will get handled but it will take a bit over a week since it's not 
convenient to do that now.

One has to ask why the old arch-release file is for.

Also interesting to learn is if this os-release is purely arch, or if any other 
distros will use it, and what the actual data will look like.

So this is accepted but marked as an enhancement, not a defect.

Original comment by inxi-...@techpatterns.com on 7 Jul 2012 at 9:02

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

http://0pointer.de/blog/projects/os-release
http://www.freedesktop.org/software/systemd/man/os-release.html
This is not Arch inventing a new standard, it's Arch following the new standard.
According to the first link, most new distros have this now, even those that do 
not use systemd.

Original comment by ne.tet...@gmail.com on 8 Jul 2012 at 2:19

[GoogleCodeExporter]

Right you are, I was somewhat puzzled by this, since this is precisely what 
/etc/lsb-release was supposed to do. But I guess that didn't catch on, now 
we'll see if a new simple text file format will.

I'll have to collect some data on this one to see how realworld adoption is 
going, and what the actual contents of the file actually is distro and release 
by distro and release. I expect more randomness, as usually is the case.

New defaults are actually quite difficult to handle because of the wide range 
of possible methods distros and derived distros have at their disposal, so 
we'll need to see the actual data.

And also, we'll need to see where /etc/lsb-release stands in relation to 
os-release as the preferred default.

How gnu/linux can make something as trivially simple as a distro id plain text 
file is really quite astounding.

Original comment by inxi-...@techpatterns.com on 30 Jul 2012 at 6:57

[GoogleCodeExporter]

After collecting data, as I expected, the os-release file is NOT being used in 
any meaningful way, all it shows at best so far is the distribution base, ie, 
if it's a debian derived distro like antix, then it would show that it's debian.

So this file will only be useful for specific cases as a last fall back, the 
question is, fall back after or before lsb-release?

For arch, as long as it has the specific arch-release or version or whatever 
that /etc file is, it should be ID'ing arch as Arch Linux no matter what, 
that's handled. If arch has stopped shipping with that file, I'll update the 
default file checks, but, as with lsb-release, os-release is not very useful to 
actually id the distro so far, no data from the fedora/suse and other branches, 
just the debian/ubuntu stuff so far for os-release.

gnu/linux would really do itself a big favor if it would just adopt a single 
real format, lsb-release was pretty close but it was missing the critical 
SYSTEM_BASE= type fields, which would allow for derived distros and all that as 
well.

And os-release seems to show on average even less.

So I'm going to leave this one as active, but wait for more data. So far I 
don't think distros will fail to id, if one does, post all relevant distro id 
files and their content here or on http://techpatterns.com/forums/ and I'll 
look into it.

Original comment by inxi-...@techpatterns.com on 24 Aug 2012 at 7:30

[GoogleCodeExporter]

/etc/arch-release is always empty only still exists for things that check for 
it's existence to know if the system is running arch[1][2].
Inxi seems to just use /etc/issue anyway, even if i put something in 
/etc/arch-release and delete /etc/issue: http://sprunge.us/UXfT
Using the latest inxi from svn trunk.

My /etc/os-release (sorry for not providing this earlier): 
http://sprunge.us/SOcX
I can't find any other files that provide distro information on arch.

[1] https://bugs.archlinux.org/task/7163
[2] https://bbs.archlinux.org/viewtopic.php?id=86414

Original comment by ne.tet...@gmail.com on 24 Aug 2012 at 8:51

[GoogleCodeExporter]

I've added in os-release now as a last fallback, after lsb-release, but I want 
to note the absurdity of having introduced lsb-release then having most people 
ignore it, then introducing os-release, and having that be even less 
informative than lsb-release was.

What the point of that was is beyond me, not Arches fault, but I think distros 
could have agreed to follow the original attempt to create a standard format, 
not ignore it then make a new one, that likewise will be improperly used.

But inxi now supports os-release, under certain very restrictive circumstances, 
and as default if os-release is present for Arch linux.

For all other cases, if the initial version detection fails, and if lsb-release 
is present, inxi will  use that, and if that is not available, inxi will try 
os-release as the final step.

I've also fixed slightly the use of /etc/issue for older Arch installs that 
might not be using /etc/os-release.

We'll see how that goes.

Original comment by inxi-...@techpatterns.com on 4 Oct 2012 at 1:43

• Changed state: Fixed