From Newsgroup: alt.os.linux.slackware
On 2026-05-28, Henrik Carlqvist wrote:
... In my case, I bite that bullet whenever I upgrade to a new
version of Slackware.
Right; Upgrading to a new OS version is already going to be disruptive
anyway, so perhaps longer disruption, but less frequent "suffering".
... as long as you stay on a stable version of Slackware, official
Slackware package updates usually do not break things.
In general, I do stay with the stable releases, but I recently
(well, it was last December, so perhaps "recently" only in terms of
Slackware release intervals? ;-) moved my personal workstation (and more recently one other system) to Slackware-current because I was finding
it progressively harder to just shrug off the aging of the installed
software (and unable to update some packages of which I really wanted
newer versions). Mind you, the workstation was still at Slackware-14.2,
so even compared to my other systems it was out of date. I'd left it
at 14.2 for so long simply because I dread updating the day-to-day
workstation (see my comment above about the OS update being rather
disruptive), and ultimately switched it to current rather than 15.0 in
order to simply not have to worry about that disruption again, while
still having the benefit of a more up-to-date environment. I really
haven't been sorry about that update, though some of my systems (the "infrastructure" systems mentioned in an earlier post) are certainly
best left on the latest stable release with regular patching.
... and I don't update "current" daily either. I apply updates as
part of my routine patching cycle, when I apply security patches to
the other systems. I treat "current" no differently than any stable
Slackware release, from that perspective.
Whenever I jump on to a new version of Slackware I spend about 100
hours to configure it as I want and add third party software. For
that reason, during the years, I have not jumped on to every new
version of Slackware.
I hear you, and have followed a similar philosophy, at least until the
end of last year, when I decided it was time to bring the workstation
into the 21st century. I may ultimately do the same with one (or
both?) of my laptops (though they're at Slackware-15.0, so not nearly
as annoyingly out of date as the workstation was).
However, about once every third year it might be a good idea to update
and lately there have been many years between the stable versions.
Yes, but again ... updating the workstation needs some psychological preparation. I had the same trouble with my workstation at work.
I always felt that I was just too busy to take a day (or two) to put
a newer version of Slackware on it. Every once in a while, though
(usually a few years after the "next" Slackware version had been
released; chances are only after security updates would cease for
the Slackware version running on the workstation) I'd give in ...
Maybe you also prefer to run Slackware current rather than a stable
version of Slackware?
On my workstation, *now*, yes, but that's still mostly new to me.
I've even installed the build toolchain from "testing", but this is a
major deviation from my usual approach. This was my very first look
at Slackware-current. Contrary to what one might expect, though, it
*is* quite stable, despite it being "-current". I expect that when Slackware-15.1 (or 16.0, or whatever it'll be called) is released,
I'll probably want to stay with that, rather than move immediately
to the *next* "-current", at least for a year or two, to let the
stability settle back in.
It makes sense for a bleeding edge distribution like Fedora to
maintain such a database keeping track of the latest version of
every software.
Right. Understand, though, that I'm not aiming for Slackware (or
even just my own Slackware systems) to be in any way like Fedora or
any other bleeding-edge system. I was looking to solve a particular
problem with trying to keep track of when new versions are released
of software that I have built and installed locally (because for the
most part there aren't any official Slackware packages for these),
many of which are more than a few years out of date.
There's nothing "bleeding-edge" about wanting to keep up with
current versions of cfengine or freeradius, for example, but in
both cases, the versions that I have used for years are so far
behind the current versions that I need to start over from scratch.
The cfengine developers accepted a patch that I submitted to make it
not identify Slackware as "Unknown", but by the time I'd submitted
that, they had already released their latest version (so although
I'm no longer ... wow ... well over a decade behind with that one,
I'm still behind yet again ... and actually, I did update freeradius
last year, so it's not as far behind as I'm suggesting.)
I'm not suggesting that I (or anyone using my script) should immediately
jump to update locally installed software as soon as a new version is available, either. The script is intended only to help track what of
the installed software it's configured to track has a newer version
available than what is installed on a local system. The idea is to
decrease the work involved in *knowing* about the availability of
an update. The decision to apply the update or not still rests with
the human.
... I really like the convenience of the stock Slackware packages
getting official security updates.
So do I, of course. Keep in mind that all that we're discussing here
(and what I presented as the reasoning behind my script) are locally
built and installed software packages. There aren't going to be any
official security updates for those from Slackware. You need to look
for them yourself. (... and I haven't been very good at doing that
consistently ... thus the desire to automate the search)
The third party multilib and compat32 packages do also get updates
on some kind of "best effort basis", ...
... but again these aren't locally built packages.
... Packages from slackbuilds.org differ very much in freshness
depending on their maintainers.
Indeed, and these *are* locally built. Many of them might even be
far out of date (at least of those that I've checked on; I mostly use SlackBuild.org more as a reference, rather than a source for build
scripts; "how did this package get handled by that maintainer").
Yes, at work there are more software packages and to those software
packages I also add my custom configuration packages. ...
Right. Do you ever find yourself wishing you'd had a chance to
know sooner that a newer version of a certain piece of software
was available? Your work environment (if my memory serves) is not
very different from what mine was, and in my case, if a user needed
a particular (usually newer than we already had installed) version
of some software, we'd find out about its existence through them.
It would have been nice in at least a few instances to just have it
already available.
The tool that I use both to check if my third party packages are up-to-
date and to install third party packages is slpkg.
I'm not familiar with that. Mostly, though, (perhaps with a small
number of exceptions), I don't install pre-built third-party packages.
I build locally into a Slackware-compatible package, and install that.
However, I take most of my third party packages from
slackbuilds.org. Also, I usually do not upgrade my third party
packages just because there is a new version.
I mostly don't either, and the script I wrote yesterday isn't intended
for that. It *is* however, intended to help me keep up with *knowing*
that a new version is available so that I can decide to update it
if it seems appropriate to do so. I certainly will update more
frequently than I have in the past, now that I know new versions
are available, but it isn't going to be a case of "drop everything,
there's a new version of $software available." The idea here isn't "bleeding-edge"; it's "let's give ourselves a chance to keep locally
built and installed packages from becoming quaintly archaic."
... if someone wants some new version of a tool or a library like
cuda I keep the old version installed on the system disk and add
the new version to an NFS disk where users get access to newer
versions with a tool which much resembles Environment Modules: https://modules.readthedocs.io/en/latest/ Such a solution allows
different users to use different versions of the same software for
different purposes.
We used Environment Modules at work. They probably still do.
That works very well in that environment.
The nice thing with your tool is that it will show the latest
version from upstream while slpkg only shows the latest version
supported by the SlackBuild script maintainer.
Right, and in my case since not all the software I've installed
locally even has a slackbuild.org maintainer (and in many cases
where there is one, I already have a newer version installed than
they have on the site), just depending on that wasn't going to be
suitable for me. However, your comment suggests to me that the
SlackBuild script maintainers themselves *could* use my script just
to monitor the packages for which they maintain SlackBuild scripts.
It would reduce the amount of work involved in just knowing that new
versions are available.
However, slpkg is only used to check for updates and initial build
of Slackware packages. All my Slackware systems mount an NFS share
containing the slackware64 directory for their Slackware version.
Yes, I keep a local mirror as well. It's much easier to maintain
even a small number of systems that way.
... It also contains a directory "cus" with my custom packages and
"opt" which contains packages I only install on some machines ...
... *that* I haven't done on my local mirror, but I have pondered
something very similar.
... And most of all it contains a directory called "updates" which
contains symbolic links to updated packages in the patches directory
or in my "cus" directory.
ohhh... that's too much manual maintenance, at least in how I'm
imagining your updates directory is populated. Consider this code
snippet, which might help you not need that (or, I suppose, might
already be how you populate that directory?)
for package in $( ls $SRCPATH/$series/*.t?z | sort -V |\
awk -F/ '{ match ( $NF, /-[0-9]/ )
if ( RSTART > 0 ) {
pkg = substr ( $NF, 1, RSTART-1 )
a[pkg] = $NF
}
} END {
for ( i in a ) print a[i] | "sort"
}'
); do
... do something with $package ...
done
In that directory, there is also a copy of /etc/slackware-version
and a Makefile which makes sure that all linked packages have or get
their corresponding entry below /var/ log/packages after checking
that it is run on the right version of Slackware (I once made the
mistake to manually run make in the wrong directory). This Makefile
is called from a cron job in /etc/cron.hourly.
sounds similar to one of my own worst blunders: pointing upgradepkg to a
a set of updates for the wrong architecture (and I probably also pointed
to the right architecture but wrong OS version at least once ...)
--
----------------------------------------------------------------------
Sylvain Robitaille
syl@therockgarden.ca ----------------------------------------------------------------------
--- Synchronet 3.22a-Linux NewsLink 1.2