[SOLVED] Any chance of Slackware including /etc/os-release?
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
+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.
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.
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.
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.
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.
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?
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.
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.
Quote:
Originally Posted by brianL
How many non-Slackware using developers write software for Slackware? Not many, if any?
That is not a reason to make it harder for them to take Slackware into account.
Quote:
Originally Posted by philanc
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.
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.
Quote:
Originally Posted by zithro
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 ?
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?
I suspect the author of screenfetch would appreciate it.
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.
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 (...)
Interesting. Thanks for having taken the time to explain.
So, +1 for /etc/os-release inclusion, given the benefits.
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.
Last edited by Eternal_Newbie; 08-21-2012 at 06:24 PM.
Reason: spleng
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.