LinuxQuestions.org
Latest LQ Deal: Linux Power User Bundle
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices


Reply
  Search this Thread
Old 04-03-2018, 06:06 PM   #16
allend
Senior Member
 
Registered: Oct 2003
Location: Melbourne
Distribution: Slackware-current
Posts: 4,983

Rep: Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728Reputation: 1728

Both /etc/slackware-version and /etc/os-release are supplied in the aaa_base package. This package is not generally updated in a -current cycle. Also, how could you ensure that that package had been updated by someone using -current?
If you want those files updated, I suggest you do it for yourself.

Quote:
Similar argument for change logs. Some Slackers use different tools and methods to update systems.
The ChangeLog is your single source of truth for official updates, no matter what tool or method is used.
 
1 members found this post helpful.
Old 04-03-2018, 07:36 PM   #17
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 702
Blog Entries: 25

Rep: Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821
Quote:
Originally Posted by allend View Post
Both /etc/slackware-version and /etc/os-release are supplied in the aaa_base package. This package is not generally updated in a -current cycle. Also, how could you ensure that that package had been updated by someone using -current?
If you want those files updated, I suggest you do it for yourself.
If no official marker is implemented, I will do it on my own systems, but then it would only work that way on my own systems. A standardized solution would be better, so that detection scripts could work the same way for everyone.

You might have the "SeTconfig" script do something like this (thus running after packages have been installed):

Code:
if [ -e $TMP/SeTDS ]; then
    DS="`cat $TMP/SeTDS`"
    if [ -e $DS/current-id ]; then
        grep -v current $T_PX/etc/os-release > $TMP/os-release
        cat $TMP/os-release $DS/current-id > $T_PX/etc/os-release
    fi
fi
.. and then have "slackware64/current-id" present on -current install media and not present on stable release install media, containing the single line "VERSION_CODENAME=current".

Doubtless others will chime in with better ways to implement this. It's the sort of task where there are a lot of ways to do it. I'd be very happy with any reasonable implementation.

Because Slackware is so splendidly versatile, there are always going to be ways to make an undetectably -current or stable/-current hybrid installation, but that's okay. I don't think anyone's asking for an airtight 100% solution. A "best effort" implementation which covers the common cases should be enough.
 
1 members found this post helpful.
Old 04-04-2018, 01:40 AM   #18
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 789

Rep: Reputation: 289Reputation: 289Reputation: 289
Quote:
Originally Posted by kjhambrick View Post
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:
I would say we already have this with the "-current" suffix.
 
Old 04-04-2018, 01:41 AM   #19
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 789

Rep: Reputation: 289Reputation: 289Reputation: 289
Quote:
Originally Posted by rkfb View Post
What determines a system running -current?

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?
My two cents:

With the first, I would say yes, still -current.
With the second, nope, a package or packages does not make a versioned Slackware-current. It's all or nothing.
 
Old 04-04-2018, 10:12 AM   #20
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 702
Blog Entries: 25

Rep: Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821
Quote:
Originally Posted by chrisretusn View Post
I would say we already have this with the "-current" suffix.
Agreed, but it remains to have it in /etc/os-release or /etc/slackware-version.
 
Old 04-10-2018, 07:11 AM   #21
kjhambrick
Senior Member
 
Registered: Jul 2005
Location: Round Rock, TX
Distribution: Slackware64 14.2 + Multilib
Posts: 1,368

Rep: Reputation: 751Reputation: 751Reputation: 751Reputation: 751Reputation: 751Reputation: 751Reputation: 751
Quote:
Originally Posted by chrisretusn View Post
My two cents:

With the first, I would say yes, still -current.
With the second, nope, a package or packages does not make a versioned Slackware-current. It's all or nothing.
chrisretusn --

As drmozes said, -current does not tell me WHICH -current I've been following.

Quote:
Originally Posted by drmozes View Post
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.
Thinking about it some more, my idea of changing ONLY /etc/slackware-version in the ~/a/aaa_base Package is insufficient -- by the time I would see the change to /etc/slackware-version it would be too late -- aaa_base would have already been installed.

For example I had to install current ( pre-14.2 ) when I installed Slackware on my latest Skylake-Based Work Laptop.

This is because I needed the Kernel, Modules, Firmware and Utilities and etc for full support of my 'new' hardware.

However, when 14.2 was released. I wanted to drop off -current and stay with 14.2 because this is my work Laptop.

This meant I had to watch for Pat and the team to announce the release of 14.2 and I had to switch over from current to 14.2 in my update script config files.

Otherwise, if I missed the cutoff, I might pollute my virgin 14.2 Laptop with post-14.2 -current packages.

I watched the change logs and all went well -- I cloned my local -current mirror as 14.2 and edited my config files and set up Alien Bob's `rsync_current.sh` for 14.2 instead of -current before downloading again -- it was seamless except for having to 'look before I leapt' with `rsync` and `upgradepkg`.

OTOH, I would be able to auto-detect the switch if there was a copy of /etc/slackware-version in the Slackware repo 'root' directory ( i.e. adjacent to ChangeLog.txt and the like ).

Maybe call the file in the Slackware root directory SLACKWARE-VERSION ?

This way, I could `wget` the SLACKWARE-VERSION file for my $ARCH from my favorite mirror and compare the content to /etc/slackware-version ...

If SLACKWARE-VERSION matches /etc/slackware-version then there has been no new Slackware Release -- current is the same current I upgraded against 'last time' -- continue with my updates from -current.

OTOH, if SLACKWARE-VERSION has changed, then -current has moved on and I have a decision to make: Keep following -current or stay with the newly released latest stable version ?

But at least I can decide without polluting my system.

This would work even without the suffix that I suggested earlier ( 14.2+ for post-14.2 current ).

Anyhow ... More Thinking Aloud ...

-- kjh
 
Old 04-10-2018, 08:46 AM   #22
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,240
Blog Entries: 4

Rep: Reputation: Disabled
It's even more complicated than that. Look at the 14.2 changelog and observe what happened between Tue Dec 29 04:45:53 UTC 2015 and Thu Jun 30 20:26:57 UTC 2016. Throughout this time period, the pre-14.2 current identified itself as 14.2. This was the same in previous cycles too. So Patrick's normal (and quite logical) workflow is to bump aaa_base when he feels close, and then make an indeterminate amount of fixes, wait until he's happy, and then to rename the -current tree completely unchanged except for the announcement in the top of the changelog.

This feature request is, in effect, asking Patrick to change his workflow so that his last action before release is to update aaa_base. If he doesn't take up this request, that'll be the reason why not.

Anyway, it's already easy to detect -current.

If the user is using slackpkg -- and really, slackpkg is the only practical way of following -current -- just look at the mirror name. It's even easy to detect the aaa_base bumped situation I described above: does the changelog contain 'is released' for the version of Slackware in /etc/os-release?

If the user is not using slackpkg, look at /var/log/packages to examine the version of the first divergent package of this cycle. In the case of pre-15.0, that was file-5.28-x86_64-1.txz on Sun Jul 3 19:29:33 UTC 2016. So if it says it's 14.2, but there's no /var/log/packages/file-5.25-*, it's -current. Yes, this will need to be a different package for each new cycle, but it's fail-safe and only needs fixing once every two years.

And finally, if the user doesn't use slackpkg and doesn't have an installation that includes the 'file' package, or is still running the pre-14.2 or pre-14.1 or other -current, they are so far off Planet Slackware that they don't deserve help from us earthlings.

And finally finally, I hope you all realise that /etc/os-release is a Lennart invention. Where are all the threads to tell us how to remove this abomination?
 
4 members found this post helpful.
Old 04-10-2018, 10:57 AM   #23
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 702
Blog Entries: 25

Rep: Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821
Quote:
Originally Posted by 55020 View Post
request is, in effect, asking Patrick to change his workflow so that his last action before release is to update aaa_base.
.. or not. See post #17 in this thread for an alternative, lower-impact method.
 
Old 04-11-2018, 11:41 AM   #24
chrisretusn
Member
 
Registered: Dec 2005
Location: Philippines
Distribution: Slackware
Posts: 789

Rep: Reputation: 289Reputation: 289Reputation: 289
Quote:
Originally Posted by kjhambrick View Post
chrisretusn --

As drmozes said, -current does not tell me WHICH -current I've been following.
Well okay, but that sort of boggles my mind.
There is only one -current, at least to my way of thinking. That would be the latest -current. Once -current goes versioned, it's no longer -current.
 
Old 04-11-2018, 12:24 PM   #25
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,212

Rep: Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986
Quote:
Originally Posted by chrisretusn View Post
Well okay, but that sort of boggles my mind.
There is only one -current, at least to my way of thinking. That would be the latest -current. Once -current goes versioned, it's no longer -current.
I think the thing people are wanting to know is what is the latest date of changes that are installed on their system while running -current. If you installed -current 4 months ago and then updated it for two months, but then got lazy/busy and it's been a few months since you updated. What can you use to determine where you left off? As it stands, there's nothing included in Slackware that can tell you that without you running some sort of command to compare what's in your /var/log/packages/ with what's on the ChangeLog. I think some are looking for something a bit more easily accessible, however, I don't see any easy way to implement this unless Pat decides to create a new package with the -current date and time from the ChangeLog that is stored in a file (or at least modify an existing package to list that information in some file and then have it included on every update).

As an alternative, maybe someone could make an addon for slackpkg (like with slackpkg+, so it could be a separate addition that Pat doesn't have to maintain) so if a -current mirror is selected, when an upgrade-all is ran, it can grab the latest date and time from the changelog and put that information in a file somewhere (/etc/os-release and/or /etc/slackware-version seem the obvious choices). They could make it a variable that can be sourced like CURR_VER=20180410233857 (or add in some dashes and/or colons to make it a bit easier to read CURR_VER=20180410-23:35:57). This could also be used in a stable release to monitor how up-to-date a system is with patches. However, this could lead to some difficulty with updates for those who use slackpkg+ (unless the person who makes this change is able to update that variable when the system is updated from official sources and not 3rd-party mirrors). If I had more time, I might try and tackle this, but I'm in the middle of selling my house and moving across the country, so my free time is severely limited.
 
Old 04-11-2018, 04:43 PM   #26
55020
Senior Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 1,240
Blog Entries: 4

Rep: Reputation: Disabled
Quote:
Originally Posted by bassmadrigal View Post
if a -current mirror is selected, when an upgrade-all is ran, it can grab the latest date and time from the changelog
The changelog from the most recent 'slackpkg update' is at /var/lib/slackpkg/ChangeLog.txt. So we just want to know whether the user ran 'slackpkg upgrade-all' after that update. That's easily answered: just break out the first package name from /var/lib/slackpkg/ChangeLog.txt [1] and look in /var/log/packages to see if that file is present. If it is, the first line of ChangeLog.txt is the date-time that identifies the user's -current. If it isn't, go to the next section of ChangeLog.txt (delimited by '+--------------------------+') and repeat.

That's an easy awk script or perl script to write. It's also easy in bash, but would be horribly slow.

[1] You'd need to ignore extra/ testing/ and pasture/, and package removals.

Edit: late congrats on your 5000th post btw

Last edited by 55020; 04-11-2018 at 04:45 PM.
 
2 members found this post helpful.
Old 04-11-2018, 08:23 PM   #27
Richard Cranium
Senior Member
 
Registered: Apr 2009
Location: Carrollton, Texas
Distribution: Slackware64 14.2
Posts: 3,000

Rep: Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374Reputation: 1374
Quote:
Originally Posted by 55020 View Post
And finally finally, I hope you all realise that /etc/os-release is a Lennart invention. Where are all the threads to tell us how to remove this abomination?
Dropping an easily parsed data file (that isn't XML at that) into /etc is not something that should trigger the Homer Simpson scream.
 
3 members found this post helpful.
Old 04-11-2018, 09:19 PM   #28
bassmadrigal
LQ Guru
 
Registered: Nov 2003
Location: West Jordan, UT, USA
Distribution: Slackware
Posts: 5,212

Rep: Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986Reputation: 2986
Quote:
Originally Posted by 55020 View Post
The changelog from the most recent 'slackpkg update' is at /var/lib/slackpkg/ChangeLog.txt. So we just want to know whether the user ran 'slackpkg upgrade-all' after that update. That's easily answered: just break out the first package name from /var/lib/slackpkg/ChangeLog.txt [1] and look in /var/log/packages to see if that file is present. If it is, the first line of ChangeLog.txt is the date-time that identifies the user's -current. If it isn't, go to the next section of ChangeLog.txt (delimited by '+--------------------------+') and repeat.

That's an easy awk script or perl script to write. It's also easy in bash, but would be horribly slow.

[1] You'd need to ignore extra/ testing/ and pasture/, and package removals.
I was just thinking of a way that it could be more automated and having it stored in an easily sourceable file rather than just running a tool that will tell you what the last date of packages that was installed. For those with a bit of scripting knowledge and are semi-familiar with slackpkg, it probably wouldn't take very long to whip something up. But I could also see the benefit of having a standalone tool (especially for those who may not use slackpkg to keep their system up-to-date)... both could be valid options depending on what users are looking for.

Quote:
Originally Posted by 55020 View Post
Edit: late congrats on your 5000th post btw
Thanks! I didn't even realize I crossed that threshold.
 
Old 04-11-2018, 10:14 PM   #29
upnort
Member
 
Registered: Oct 2014
Distribution: Slackware, Proxmox, Debian, CentOS, Ubuntu MATE
Posts: 644

Original Poster
Rep: Reputation: Disabled
Quote:
I think the thing people are wanting to know is what is the latest date of changes that are installed on their system while running -current.
Perhaps some people want that, but that was not the original focus of this (my) thread. My focus was a request for a simple scriptable way to distinguish a stable release from current. Something in /etc/os-release would suffice and be simple and is what I requested. Pat is a veteran hacker with these things. I am sure if he provides a solution the method will be simple.
 
3 members found this post helpful.
Old 04-11-2018, 11:23 PM   #30
ttk
Member
 
Registered: May 2012
Location: Sebastopol, CA
Distribution: Slackware64
Posts: 702
Blog Entries: 25

Rep: Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821Reputation: 821
Story time :-)

In 2010 my employer transferred me to a division which had about 20,000 servers as part of its infrastructure, for which I was supposed to develop ETL software.

One of my first questions was "What OS are they running?" To my surprise and consternation, nobody was able to answer that question, beyond "CentOS mostly".

I had ssh permissions for them all and a list of IP addresses, so I invoked mssh (a concurrent multi-ssh utility) to upload and run a "self-id" script on all 20,000 hosts, and redirected the script's output to a file on my workstation. http://ciar.org/ttk/codecloset/self-id

This gave me a nice tidy data table of what was what. It turned out to be mostly CentOS 5 hosts, a dismayingly large number of CentOS 4 hosts, and a handful of SuSE hosts.

That gave me a notion of the kind of environment my software needed to run in -- CentOS 4 and CentOS 5 (turned out I could ignore the SuSE systems). I would design it to depend only on resources available on both of those operating systems, and would be sure to test it on both operating systems before rolling it out to production.

Why is this relevant? Suppose some of those had been Slackware systems. My self-id script handles Slackware (of course), but it has no way of knowing whether a system is based on current or a stable release.

I would still need to know what resources my software could depend on, and what environments to test under. If I made assumptions about those based on the Slackware version number, those assumptions might be incorrect if some those those hosts were installed from current, depending on how far along they were in updates.

If a thousand hosts identified as "Slackware 14.0", and based on that I decided that I could depend on tightvnc being installed on them, but it turned out that a hundred of them were actually updated from "current" beyond Oct 14 2013, those hundred hosts would not have tightvnc installed (as that package was removed from current at that time).

And I wouldn't know that until I deployed my software and it broke on a hundred production hosts. Oops! Suddenly it's a very bad day.

I'd much rather have my self-id script tell me when a system is based on "current", so that I could flag those hosts for further attention, or perhaps not deploy my software to them at all. It would be an indication that I couldn't make assumptions about the environment based on its stable release version number, and that would be enough to avert disaster.

That's one scenario. It's not the only one, but it's the one that came to mind when I saw this thread.
 
4 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Script to build always a current ISO image of Slackware (slackware-current) robertjinx Slackware 2 12-09-2010 02:00 AM
[SOLVED] How to identify current CPU in a parallel machine Feynman Linux - Newbie 6 09-03-2010 09:57 AM
Identify current mode of a file scbops Programming 2 07-03-2006 08:41 AM
Identify Slackware as Windows rkfb Slackware 17 05-02-2004 06:52 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware

All times are GMT -5. The time now is 07:12 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration