[SOLVED] How to identify Slackware Current? (Feature Request)
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.
How to identify Slackware Current? (Feature Request)
Likely I am overlooking something obvious. More than possible because most days I can't see the tip of my nose!
I am looking for a scriptable way to identify a Slackware Current system and distinguish from a Slackware stable system. Mostly when supporting multiple Slackware systems.
A person using Current knows that Current is being used. A script does not know.
I created a Current VM. I was looking for something simple, such as using /etc/slackware-version and /etc/os-release. Using those files in a stable release "just works," but in Current those files remain unchanged during the development cycle. Traditionally those files do not change until heading into formal beta testing. Likewise with package name schemes.
As those two files are intended to help users identify a system, would be nice if perhaps at least PRETTY_NAME in /etc/os-release was different.
Other methods might include /etc/motd and kernel versions, but those methods could fail if a person has reason to use a different kernel version in a stable release. Other options might include comparing ChangeLog.txt, FILELIST.TXT, PACKAGES.TXT, or noting /patches/packages does not exist, or looking at the mirror used in /etc/slackpkg/mirrors -- if a person uses slackpkg.
This is not a thread about using Current (use at your own risk, blah, blah, blah). Just a simple conversation about a scriptable way to identify a Current system.
I'd write a script that downloads a -current ChangeLog.txt, parses the installed packages in reverse order in /var/log/packages/ and then determine whether this computer is synced to a specific date of -current updates. You'd need to verify multiple packages to be certain - for instance all the packages attributed to a single batch of updates.
Other methods might include /etc/motd and kernel versions, but those methods could fail if a person has reason to use a different kernel version in a stable release.
If you are using a different kernel version than -stable is using, then how can you say that you are running a -stable system?
Seems to me that you have these Slackware systems:
-current
-stable
user defined
"user defined" may need to look through old release kernel versions to provide a hint that perhaps you haven't upgraded your kernel. Of course, the first release of -current normally has the -stable kernel in it.
OTOH, adding VARIANT_ID=current to /etc/os-release for -current and VARIANT_ID=stable for -stable would simplify your problem. See https://www.freedesktop.org/software...s-release.html (To Whom It May Concern: Just because a string has systemd in it is no reason to become silly; that is all.)
Based on the responses looks like I am not missing anything obvious.
Seems /etc/os-release has additional options that could be used to identify Current without breaking existing variables that others might already be scripting.
What if I upgrade to current but don't upgrade the kernel? Am I still -current?
What if I run 14.2 but install a particular package from the -current tree because I want the newest version? What if I install half a dozen packages?
I could end up running a sort of hybrid system if I was determined enough I guess. Are there certain packages that absolutely determine what a system is or is it just the case that every system is user-defined?
I should imagine that the only true current systems are the vanilla install development systems run by the likes of Pat and Eric.
What if I upgrade to current but don't upgrade the kernel? Am I still -current?
What if I run 14.2 but install a particular package from the -current tree because I want the newest version? What if I install half a dozen packages?
I could end up running a sort of hybrid system if I was determined enough I guess. Are there certain packages that absolutely determine what a system is or is it just the case that every system is user-defined?
I thought the same: a -current from a year ago that was installed and never updated, would still be flagged as being "-current"; so it depends what you want this script to achieve.
I think that the distinction would primitive: it's either a known release (indicated by a version number) which may or may not have been updated (using /patches and/or locally installed packages), or it's not (could be "-current" from any period of time).
The only other practical option I could think of would be to indicate that it's "-current" _post_ a released version, which would give you some idea of the system.
I wouldn't want to make any automated decisions based on this information though, unless the management of the machines was known in advance.
Location: Geneva - Switzerland ( Bordeaux - France / Montreal - QC - Canada)
Distribution: Slackware 14.2 - 32/64bit
Posts: 609
Rep:
Quote:
Originally Posted by drmozes
I wouldn't want to make any automated decisions based on this information though, unless the management of the machines was known in advance.
Sorry to correct you but you assume the "test" too quickly... The test might just be to automatically detects we DON'T support the -current branch. Information worth what people do about it. Never assume "usefulness" of an information, moreover when you deal with developers (/hackers). So yes, I'd make an automatic warning / abort with this information. This is automated, this is a decision.
What if I upgrade to current but don't upgrade the kernel? Am I still -current?
What if I run 14.2 but install a particular package from the -current tree because I want the newest version? What if I install half a dozen packages?
I could end up running a sort of hybrid system if I was determined enough I guess. Are there certain packages that absolutely determine what a system is or is it just the case that every system is user-defined?
I should imagine that the only true current systems are the vanilla install development systems run by the likes of Pat and Eric.
Going along with the idea of using something like /etc/os-release to identify the Slackware version, a -current system would be one that has upgraded the package containing that file to the one from -current. The assumption would be that if you have upgraded that package, then you have probably upgraded everything else too. Is that necessarily an accurate assumption? Of course not, but in those cases the admin is expected to know that he/she has created a mixed system. This solution would at least catch the majority of cases where someone switched to a -current mirror accidentally.
I'd write a script that downloads a -current ChangeLog.txt, parses the installed packages in reverse order in /var/log/packages/ and then determine whether this computer is synced to a specific date of -current updates. You'd need to verify multiple packages to be certain - for instance all the packages attributed to a single batch of updates.
This one-liner will show matches between a -current ChangeLog.txt and installed packages.
This solution would at least catch the majority of cases where someone switched to a -current mirror accidentally.
If this was done uncommenting a -current mirror in /etc/slackpkg/mirrors, the user will be warned next time slackpkg runs if and when Robby's patched slackpkg is uploaded to -current, see lines 266-282 in this file.
Last edited by Didier Spaier; 04-03-2018 at 08:32 AM.
Not all Slackers use slackpkg. The slackpkg mirror would not help Slackers who use pkgtools or slapt-get.
Similar argument for change logs. Some Slackers use different tools and methods to update systems.
While Pat is not responsible for Slackware derivatives, would still be nice if the method used rolls down hill to the derivatives in a compatible way.
Basic expectations remain the same whether a person is running stable or current, modified or unmodified. What users do downstream is not the maintainers' responsibility. Maintainers must be allowed some simple presumptions. For example, a long-standing presumption when asking for help in this forum is running a full installation and if not, to be specific about what is not installed before seeking help. Nobody is required to run a full install -- I don't and haven't for many years -- but I expect myself to know the impact of what is removed.
I am thinking a single new variable in /etc/os-release would be sufficient to distinguish releases. Anyway, I am hoping Pat agrees.
Since we don't know the next Slackware version number when a new stable version is released, I wonder if a very simple suffix in /etc/slackware-version would work ?
Maybe for current, add some sort of predictable suffix to indicate that you're in a -current version, based on the previous stable version:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.