What I do is pretty simple; I keep all my systems at stable, subscribe to the security mail list, manually download packages and apply the updates. I keep them in /usr/local/patches and spin them to other systems (via scp) and manually upgrade.

I download from OSUOSL with wget, one of today's downloads:
I use command line editing to simply change enough of the package name (it was mozilla-nss*, changed it to bind*).

I know I can automate it, I don't want to, I prefer spending the time and having control.

Every once in a while I blow away the content of /usr/local/patches and download the entire thing again just to make sure I get non-security patches (I don't really read the change logs, lazy). Once downloaded,
That only patches anything that is newer than what's already there. Simple.

I support a couple of folks that have 32-bit (and I have two 32-bit boxes) and a couple that have 64-bit systems. No big deal, download the entire archive twice into different directories, burn them on a flash drive, spend a little quality time with the folks I support (and get coffee and cookies to boot). Update via sneaker net and driving around a little. Get some fresh air (and don't forget the coffee and cookies and, sometimes, donuts or maybe carrot cake).

Is it a burden? Well, no, only takes about five minutes to download the entire archive, five for 32-, another five for 64-bit. Folks I support don't have super zoomie Internet connections, I do, no big deal.

And, OP, if you're running 64-bit boxes, make sure you get the kernel patches and apply them if you haven't done that, might want to do that first.

Slackware is kept up to date via patched packages, you find out about those with the security mail list plus, every so often, go read though the change log for non-security patches.

Or, just follow the excellent advise in posts up above and automate the process if that floats your boat. Either way, it's worth what little time you have to take to keep things running smoothly.

Hope this helps some.

5 members found this post helpful.

I'm also a proponent of the rsync approach, though there's nothing wrong with using slackpkg if it suits you.

Interesting. I took the term "automated" to mean updating with little or no user interaction. Some distros prompt you with an icon letting you know that updates are ready to be installed. I have manually installed updates in the past with Slackware. These days I like and use slackpkg.

I think it's the over reliance on slackpkg that hurts good administrative tactics. Rsyncing packages and sources allows you to use the changelogs to patch and build locally or use vanilla packages, if they have no specialized patches needed, and gives you complete control. How do people miss this? Do we need a HowToRsyncAndLocalAdmin.txt on the install/boot media?

I like slackpkg myself, but I'm not corporate IT where rsyncing should be used.

1 members found this post helpful.

I do something similar but with my own script:

https://gist.github.com/ruario/9673751

Using wget, it syncs patches only for the official packages I have installed (no point downloading KDE updates if you don't have KDE), for the stable Slackware version I am running, using a mirror found via mirrors.slackware.com. Then it checks their signatures.

Upgrades are done via upgradepkg.

EDIT: It handles blacklisting updates as well.

3 members found this post helpful.

On my public servers I'm using slackpkg, but only after reading the ChangeLogs (with the morning coffee). On client's networks (schools etc.) I keep a local Slackware (and MLED) repository, and all the client desktops are in sync with that local repository.

On a side note, that's one thing that works really great on Debian and derivatives: the package proxy Apt-Cacher. Badly missing on all non-Debian distributions.

Cheers,

Niki

1 members found this post helpful.

That's exactly what I think when I see threads like this as well. If you've made up your mind to do something already, there's no point in making up a thread to tell other people so. That smacks of attention-getting/drama, and I tend to think little of those kinds of people (This may be an exception, however)

"Assisted" might be a more appropriate word for what I do. The script I use compares the available packages on my system to the installed packages (identified from /var/log/packages) and then generates lists of packages to be installed, removed, or upgraded. It's just a way of not having to manually work through the changelog doing the installpkg/upgradepkg/removepkg for each package. I still give it full oversight and don't run it blindly (although I probably could do so and get away with doing that most the time).

For example, here's today's updates (plus a new kernel from my local packages directory) which I'm just about to apply:
So, I run my script (which does nothing but generate a list on stdout), and then if I'm happy with what I see, I run
slacklist upgrade | sort | xargs -r upgradepkg

The rsync I use is a fairly simple:
... which will run to about 1.6GB of diskspace, and is IMO more than worth it for the convenience of having ready access to all the packages (with the exception of KDE/KDEI) should something go wrong and things need to be reinstalled.


It also works for a stable release. You just add .../patches/packages to the list of directories slacklist scans for package files. Some people will object to setting aside a few GB of diskspace for the local mirror, but IMO it is well worth it and I view it as somewhat akin to a windows recovery partition.

I've been doing it this way for about 3 years now.

2 members found this post helpful.

While I agree the thread title could be worded with considerably less confrontational language I am also aware that IT departments aren't always logical especially toward someone who chooses to use any system not ordained by the pack. So it is entirely possible that OP wrote the title after a culmination of unreasonable pressure from people who frankly don't know shit from shinola about Slackware or even security. Many mindlessly shuffle off responsibility by doing ALL updates regardless of negative impacts exactly because they think they can say "Not my fault. They did it" This should not be taken to excuse such a long-standing member but at least to extend some empathy for dealing with morons, incapable of critical thinking or basic responsibility.

OP, take this as you will, but I too have nearly 20 years using Slackware and additionally routinely and thoroughly test other distros mainly so I can see what's going on and converse about it from experience. IMHO there exists not one distro as stable and strong as Slackware. What is perceived as time saved by automation is consumed by increasing the complexity of troubleshooting when it comes to upgrades. I sincerely hope you have seen some good ways to walk a sober line and get what is actually needed accomplished without destroying the advantages Slackware Basic offers.

If it applies, tell those morons, "We shall see whose system gets compromised first...or even ever"

9 members found this post helpful.

GazL --

I am also an rsync ; review ; ( upgrade-or-install ) kind of guy ...

I was going to write a script that compares the files rsync'd from the mirror with what's installed on my system, accounting for version strings and the 'extra stuff' after the base package name ...

It sounds like slacklist must already does most of what I need ?

can you share slacklist or is it already out there or is there some other utility that knows how to parse package names, eliminating the version strings ?

Thanks !

-- kjh

Hi,
Coming to a Slackware forum and asking for suggestion to abandon Slackware for other distributions will get you a mixed result. Maybe look at Linux - Distributions and query in the potential distribution forums that you may find interesting.

Sorry, but PV & team have provided version updates over the last 3 years. Please see the suggestion for signing up for the mailing list below.

Never! Never! Mix version packages, especially from -current. Unless you are running -current. PV & team spend a lot of time to prevent dependency issues so why would you think mixing with a newer version with a older one would work? One other note that you should know since you state 23 years experience with Slackware, Slackware -current should not be used on production equipment unless you thoroughly know how to troubleshoot/repair issues with that install when and if problems arise.

Sounds like a bad install! You did verify your downloaded ISO md5sum and burnt image verified?

You should sign up for the Slackware Mailing Lists Follow the directions on the site to get announcements for version updates.

Slackware Doc Project provides useful information to new and old Slackware users that will aid you in working with Slackware.

Hope this helps.
Have fun & enjoy!

3 members found this post helpful.

Yep, happy to. I suppose I really ought to get myself a github account for some of my stuff. I did post it on this forum once before when I first wrote it, but was met with a lack of interest. I've been toying with the idea of rewriting it in either perl or C in order to avoid having to use the temporary files and the dependence on coreutils/sed, but its been working well enough as is, so I never really got around to it.

4 members found this post helpful.

Anyone tried syncthing purported to be rsync's successor?

Thanks GazL !

The sed patterns in your script are exactly the kind of thing I am looking for ...

I want 'something' to compare what's in /var/log/packages/ to whats in my slackware rsync target ( /home/dld/slackware-current-64/ )

I want it to look both ways: missing from /var/log/packages/ and/or missing from ~/slackware-current-64/

I want it to work for new packages and patches ( packages while I am on current ; patches when / if I settle into 14.2 stable )

Eliminating those pesky version strings from the `base` package name is the 'fun' part and the heart of the project.

Thank you !

I'll throw what I've got out here when I finish.

-- kjh

Yep, that's exactly what I wrote slacklist to do.

"slacklist install" will show you what is missing from /var/log/packages (i.e. not installed), and "slacklist remove" will show you what is installed but doesn't have a package file in your mirror.

Yep, it should do that too. You just need to create the right entries in your ~/.slacklistrc file or PKGPATH env var. It really is quite flexible.

Have a play with it, you might find it already does what you need, but if you want to borrow parts of it and go your own way, then that's fine too.

1 members found this post helpful.