[SOLVED] Any chance of Slackware including /etc/os-release?
SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Any chance of Slackware including /etc/os-release?
At Opera (my employer) we often see bugs that only show up in one distro, often in a specific version of a distro. Usually we notice a trend once enough bugs or crash reports come in and we have contacted several of the people reporting them.
It would greatly speed things up for us (in terms of reproducing the bug locally and hence having a chance of fixing it) if we knew the distro (and version) up front. A handful of people remember to include this information in their bug and crash reports but sadly the vast majority do not. We have considered various ways of determining the distro automatically (looking for /etc/$DISTRO-release, /etc/$DISTRO_version, /etc/$DISTRO-version, or reading /proc/version and/or /etc/issue) but all methods have various drawbacks. Not least the fact that formatting changes drastically between each of these methods, particularly across distros and distro versions.
For a while it looked like lsb_release might fix the problem. However, that never really took off. It's an optional package in many distributions and has the downside in any case that you must call the application directly rather than reading a file (Note: Ubuntu includes the file /etc/lsb-release, which is read by their lsb_release tool, however the LSB does not standardise any such file, so its presence or format cannot be assumed in any case).
Recently, .... [drum roll] .... Lennart Poettering wrote the following on his blog:
(Please keep an open mind when reading it and don't just dismiss it due to whatever feelings you have towards Lennart, PulseAudio or systemd).
I actually quite like this idea. Not only would it solve a problem here at Opera but also for various other software companies and/or projects. I have seen distro checks in numerous other applications and scripts, so this is a common problem. It would also help on forums such as these as you could always ask a newbie to cat /etc/os-release if he/she was not providing clear information about his or her setup.
Even if Slackware manages to avoid systemd (which I hope it does) perhaps this file could still be added. It is already present in recent versions of the following distros: Angstrom, ArchLinux, Debian, Fedora, Frugalware, Gentoo, OpenSUSE, Mageia (and possibly others). Its presence in Debian will mean that it also eventually shows up in Ubuntu and Mint and its presence in Fedora will mean it ends up in RHEL, CentOS, Oracle and Scientific. These list of distros includes all the core development distros (with the exception of Slackware) to the vast majority of smaller distros out there. If Slackware adds the file as well, then I predict that within a few years the problem of distro detection will be solved (at least for modern distros).
P.S. In case anyone is wondering when reporting Opera bugs and crashes you have the option of seeing all the data we gathered and hence removing or adjusting it if you so desire.
EDIT: Since there are no doubt plenty of scripts out that there that look for /etc/slackware-version I am certainly not suggesting its removal. For backwards compatibility it will need to stay in addition to /etc/os-release. I know this is not as pretty as having one file but Slackware has always strived to do things right and keep things stable first and foremost. For that reason I want both /etc/slackware-version and /etc/os-release
Last edited by ruario; 08-26-2012 at 06:04 AM.
Reason: Added a link to the /etc/os-release man page, added a further comment about /etc/slackware-version, added more distros
@dgrames: You might want to actually read the link before replying.
EDIT: Ok, I'll be nice and summarise. /etc/slackware-version is not a standardized naming format, e.g. /etc/fedora-version does not exist on Fedora but rather /etc/fedora-release and Debian uses another naming format again by calling their file /etc/debian_version. Additionally the formatting within the files /etc/slackware-version, /etc/fedora-release and /etc/debian_version is not the same.
Therefore to write a distro checking script you actually have to already know the names of the files each of the distros use and how they format their contents internally. What happens when a new distro appears? You have to be aware of it and update your script to account for it. You will never automatically detect a new distro.
The guy kills everything that he is not being paid for. How about the good old concepts called "compatibility" "co-existence" and "cooperation"?
Indeed, I don't appreciate the way he tries to forces his stuff through by leveraging one thing to ensure another happens. That said, I still think /etc/os-release is a good idea. It fixes a legitimate problem on Linux.
Originally Posted by Lennart Poettering
Yesterday we decided to drop support for systems lacking /etc/os-release in systemd since recently the majority of the big distributions adopted /etc/os-release and many small ones did, too
Regarding the above statement of dropping of support for systems lacking /etc/os-release, he clarifies his statement on the mailing list. Rephrasing it to say it is only kinda mandatory. You can work around this by using --with-distro= on the configure line when building systemd. Or you can do neither and when a systemd-based distro boots it will now read "Welcome to Linux" in white instead of the distribution's name in the colour. Previously to requiring /etc/os-release they apparently had a method that tried to determine the distro by jumping through hoops (like we had considered). So it is not so much that systemd requires this file, it requires it if you want your distro name listed and won't consider --with-distro= when building systemd as an alternative.
EDIT: I should also add that by mandating /etc/os-release (or --with-distro= when building) a new distro who decides to use systemd will get their name printed without having to patch systemd so that it autodetect's their distro just to print the correct name. So actually this probably makes it easier for the distro maintainer and helps simplify the systemd code. Its not as bad as it sounds but I can see that his arrogant style certainly makes it read that way!
Last edited by ruario; 08-21-2012 at 10:10 AM.
Reason: Added mailing list link
A casual observation of this thread shows that there seems to be mixed feelings. But "feelings" is what is seeming to dominate. Perhaps we should be conceding that adding this file 1) costs nothing, 2) wins a bit, 3) can't hurt anything. It's not as if it's a brand new program that could crash the new release. And if it misses this release, it could take another year before the chance to remedy arises. And as @ruario points out, it could be useful for a lot of developers who write cross-(linux)-platform stuff.
I'm not expecting everyone around here to start suddenly liking Lennart. Hell, I'm no fan of the guy. But you don't need to like the guy to decide if /etc/os-release is beneficial or not. It would be nice if we could focus on that.
To get some idea of the tricks you have to employ have a look at 90linux-distro (Part of os-prober, used by the Debian installer and Grub), or perhaps the detection script used by Lynis (an auditing tool for Unix), or look at "detect_distro()" within the linked script on the Compiz-Check page. Once you start looking for it you realise there are lots of scripts doing stuff like this, reinventing the wheel over and over again and detecting different selections of distros (the ones the maintainer of the script knew or cared about). They are also all ugly hence often broken. VirtualBox is another application where I have recently seen similar style code (download one of their cross distro ".run" files and open it in less, then search for /etc/slackware-version).
I would prefer that the Common Platform Enumeration string be the only mandatory field in /etc/os-release. It is a cross platform specification.This would serve the needs of software developers.
The other fields are fluff that are not applicable in Slackware and most could be parsed from the CPE string.
I also do not like the idea of an extensible structure to /etc/os-release. This smacks of the thin end of wedge. No offence ruario, but you work for a commercial company that wants users to make use of social networking and cloud computing. Providing accessible information about private computing setups just creates more potential fields for data mining.