I use slackpk(gplus) for most systems I maintain for others.

I prefer to have a mirrored tree for my main even if I occasionally use slackpkg for new-config from time to time.

https://www.youtube.com/watch?v=JRZtkyjgW4k <--- this is what I do daily

2 members found this post helpful.

I maintain a mirror of -current and update from this with upgradepkg. Most of it scripted these days...

1 members found this post helpful.

I was using slackpkg to install upgrades on an old 32bit Intel computer with Slackware 15.0 but I have been forced to give
up using it due to its strange behavior during the slackpkg update step. It apparently tries to resolve the name of
the local ftp.lip6.fr mirror everytime it downloads a file. The name resolution take much longer than dig or nslookup. Then, the file transfer often stops with timeouts followed by retries. Upgrading a few packages can take sometimes more than 1 hour. It is much faster to download directly the packages with ftp and install them with upgradepkg. I could not to determine the cause of the problem. ftp.lip6.fr is a FreeBSD server belonging to the computer lab of University Pierre and Marie Curie, and switching HTTP/FTP or using a server in Germany does not improve anything. It also does not look like a networking issue on Slackware as I can browse the web or send email with seamonkey.
I suspect the downloader used by slackpkg to retrieve the files is the bottleneck, but I have no idea how it can br tested.

I often use the lip6 mirror without any problem. That said, I barely fire up my last 32bits system.
Might worth some vm test.

I use slackscan by GazL. I find it much more flexible than slackpkg.

In particular, slackscan make it possible to use slackrepo without gen_repos_files.sh, which makes slackrepo really fast (i.e., remove slackrepo's main flaw).

2 members found this post helpful.

I have my own script that is a wrap around for pkgtool(8) and downloads for a very long time. Every so often I toy with the idea of using slackpkg, but then get lazy

1 members found this post helpful.

Assuming that "no, I don't" answers are also of interest...

Only one computer to maintain, running 15.0 (not current). I manually download patches to a directory as a regular user, su to root, install them with upgradepkg. Back as regular user I do an "ls -l *.txz >>{text file}" to track what was installed on what date, move the packages to an "installed" directory, move older versions of the same patch to a "superceded" directory. All old copies kept... This way I control what is installed, and know when.

I also drive a car with a manual transmission.

2 members found this post helpful.

I do not use slackpkg. I use slapt-get, the tools shipped in the pkgtools packages and spkg. I will try slpkg when I find the time, i.e. not soon. Caveat: I run a derivative of Slackware most of the time, to which slackpkg is not well suited. I could use it when running Slackware, although I also use slapt-get also in this case, as it comes handy to install packages from repositories providing the metadata it needs in PACKAGES.TXT, like those maintained by Eric Hameleers ot George Vlahavas.

1 members found this post helpful.

I use my own scripts.

On my server I do then decide if it needs to. doing
as stated earlier if needed. Haven't in some time.
update/ upgrade based on your need for the most current on things.

why would someone not use slackpkg?

I download manually the ChangeLog.txt and new patches with Midnight Commander on ftp.lip6.fr, verify *.asc with gpg then apply patches with upgradepkg. Also check for *.new files.

I have a directory "updates" which contains symbolic links to packages in the patches directory and another directory with custom packages. This directory also contains a copy of the file /etc/slackware-version and a Makefile with the follwing contents:

This directory is mounted by all machines in the network and they have a cron job as /etc/cron.hourly/slack_update looking like something this:

The Makefile starts by checking that it is being run on the right version of Slackware (installing packages for the wrong version of Slackware can give a really annoying result) and then updates all packages needed to be updated in alphabetical order. Sometimes this alphabetical order is important, the package management itself might become broken if the wrong package is installed too early.

regards Henrik

I see that others have mentioned maintaining a local directory or repo of packages so to add to my previous post...

I use Eric's mirror script to maintain a local mirror of the Slackware release versions that I use, and always update from those local repos, whether manually or using slackpkg. This allows a great deal of flexibility when upgrading multiple hosts, and maintains my ability to recover or install new instances to the most recently used state entirely from local repos, in the increasingly likely event we lose access to remote repos for any number of reasons.

1 members found this post helpful.