+1 for focusing on the idea rather than on the author.

The idea itself looks good, but may have little actual value for application developers: All the great examples that you referred to show that what is needed is to check that this or that feature is available.

For example, a generic os.release file telling Opera that I run Slackware 14RC2 on my PC now would not help much. I may have not installed the complete /a to /y set, I may have installed stuff from elsewhere, etc. Am I supposed to think to change my os.release file each time I change something from the fresh Slack install? change it to what?

My guess is Opera would still have to check the actual features that matter to their apps, and couldn't do much with some arbitrary os-release file...

So yes, os-release could be used for some welcome message (as it is by systemd), and maybe to redirect me to the Slackware alley of some online app store... but beyond that I am not sure it would eliminate the sort of detection scripts listed above.

Phil

Why isn't this file named 'distrib-release' because it is just this ?!
So at least we could have a 'kernel-release' file, if needed in the future (or if already existing, sry for noobness).

And why not modifying uname, by adding a distro switch ? UNIX backward compat ?

If the idea of /etc/os-release is a freedesktop standard/proposal, I see no harm in adding such a file to Slackware.

Regardless of whether a certain person continues his Quixotic quest to become a blanket party candidate, remember that even a blind hog finds an acorn every once in a while.

2 members found this post helpful.

I don't like the idea of application behaving in a different way on different distributions. So in my opinion there is no point in /etc/os-release. I know that this may end-up in a more difficult develop but this is going to be abstraction upside-down. Distribution have to ensure standards and applications have to rely on them.
I'm not going to say that /etc/os-release is harmful but also I don't want to see distro-specific applications, I think that the model of develop that this concept is advertising it's pretty dangerous.

As long as distros install stuff into different locations and configure things differently, developers are going to have to take these differences into account (i.e. behave differently on different distributions). /etc/os-release seems like a reasonable way for a developer to check what is being worked with.

2 members found this post helpful.

It can be useful for a .run installer, for example, to determine the distribution it is currently running on to produce a proper installable package. If a .run installer is generating .deb files in Slackware, then it has obviously failed (and while it may be possible to override such things via arguments, it isn't ideal). A package may also determine which init scripts/files to use based on the distribution (/etc/init.d/, /etc/rc.d/, systemd, etc.). I don't see a problem with the idea, but Poettering's explanation for it is, once again, brash. I can see the extensibility, touted as a feature, becoming a source of fragmentation. I can also see this simple idea ballooning, becoming a source of other system configurations...

As usual it appears that Lennart is over-complicating a good idea. I am not opposed to the file's inclusion but is it really necessary to allow ANSI colouring?

None taken. Personally I am pushing this because it would make my job (I'm a QA) easier. Nobody asked me to try and get distros to adopt this. In fact I doubt most of my colleagues are even aware of it.

Yes, I see your point that more could potentially be collected but all I want it for is crash and bug logs. These are uploaded in plain text which the user is free to edit.

That is not a reason to make it harder for them to take Slackware into account.

Oh you are so very wrong!

By knowing the distro (distro version) I know the exact version of the libraries on which Opera depends and which distro I should start with when attempting to repro. That is often enough. Most people do not replace the base software with different versions and you need to have Opera's dependencies installed for it to run.

Also distro specifics often turn up weird bugs. For instance recently we noticed some users were getting a crash with the Java plugin every time, other users were not. Pretty much all the users who did see the bug were running Debian-based distros. The bug was triggered by the double symlinks that Debian's alternative system setup for the Java plugin (from the Java directory to /etc/alternatives and then a symlink from there to the mozilla plugin directory). If you only had one symlink deep (most distros) you didn't see the bug.

Why does it matter?

2 members found this post helpful.

I suspect the author of screenfetch would appreciate it.

I suggest that Slackware drop support for Lennart Poettering.

5 members found this post helpful.

and your thoughts on this specific suggestion are?

1 members found this post helpful.

So it helps developers and, in its nature as a simple text file, doesn't cause anything harmful/intrusive.
I see no serious reason why not to include that.

1 members found this post helpful.

http://xkcd.com/927/

At least /etc/os-release seems to be sane enough.

1 members found this post helpful.

Good! this is the best way to learn something!

Interesting. Thanks for having taken the time to explain.

So, +1 for /etc/os-release inclusion, given the benefits.

Phil

I'm impressed, a sensible and reasonably well-thought out idea from Lennart Poettering. But as they say, even a broken clock shows the right time twice a day.

However, like zithro I think "distrib-release" or "distro-release" would be a more apt name for the file. And like allend I wonder what it might mutate into, given Poettering's history, and how long it will be before it is suddenly deprecated for arbitrary reasons.

I read this proposal from Lennart some time ago. (Although it isn't a proposal, but a justification because the decision had already been made to exclude everything else). I remember then that I thought that he was trying to solve something that shouldn't be used in the way he was solving because it can destroy portability.

Now I see this topic of discussion, and take a brief look at what Lennart was saying, and see an attempt to change something that was simple and straight-forward with yet more rules, and yet another implementation. So I guess that everyone else that doesn't have a narrow focus and wants to maintain compatibility will need to have at least four different ways just to get a piece of data. I know of a similar situation as some company who has a team defining more rules on the form of data when it is the same data as it was before. They define the requirement, but take no part in the implementation, so they have no idea the havoc they just created. Then there's no saying that it won't change again.

So my humble opinion is, again, don't give credence to Lennart's work and walk away, and rethink the problem you are solving to not depend this unreliable piece of data he was trying to standardize. There is absolutely no meaningful way you are going to handle enough cases to do anything meaningful, even if it was provided in the same form every time.