One tip is on an issue with https://slakfinder.org, another is about not upgrading some packages by default. They aren’t related to each other, but I’ve dealt with one and found a solution to the second one at about the same time. There is also an unrelated bonus section.
The tips are related to slackpkg+ (the link likely won’t open), which is useful if you have multilib installed because it allows treating it essentially the same as official Slackware packages which get masked. It’s not limited to multilib and allows managing any number of repositories in addition to the official one.
Tip #1: Timeouts on slackpkg check-updates/update
This started to happen recently and wasn’t very consistent, so I simply didn’t wait for those commands to finish and checked back on them after approximately 5 minutes. Eventually, I concluded that the issue is permanent, saw that it popped up over the years and that about 2 years ago AlienBOB set up a mirror.
Editing /etc/slackpkg/slackpkgplus.conf to replace
MIRRORPLUS['slackpkgplus']=https://slakfinder.org/slackpkg+15/
with
MIRRORPLUS['slackpkgplus']=https://slackware.nl/slackpkgplus15/
fixed everything. Although, this does mean that slackpkg+ is unmaintained at the moment and you might as well just drop its mirror. It does work fine on latest Slackware64-current and maybe AlienBOB will make some changes or update his repo when the author of slackpkg+ is back.
By the way, I think the timeout on slackpkg+ repository was causing issues for multilib repository, preventing it from being updated. So this wasn’t merely a convenience fix.
Tip #2: Not trying to upgrade AlienBOB’s packages by default
When using slackpkg+, slackpkg upgrade-all can offer a lot of downgrades
if you’ve enabled AlienBOB’s repository which isn’t always in sync with
SBO. For a while it was getting on my nerve to unselect those downgrades and
still keep the rest selected. Recently, I accidentally saw
/etc/slackpkg/greylist file with which one can automate the process simply by
adding a line like this to the file:
# Most of these packages are outdated, so deselect by default. [0-9]+alien
I still need to go through the list sometimes and check for upgrades, but that’s a much smaller problem. Ideally, downgrades wouldn’t be even suggested or it would be possible to bulk-unselect things based on the repository, but that’s not how slackpkg works. I have my version of sbopkg in the works because I find sbopkg too slow and C++ being awesome makes working with SBO packages blazingly fast, but the tool doesn’t support handling binary repositories at least yet (I’m aware that some such tools already exist, I just haven’t seen the one which I would like to use, some are even more laggy then sbopkg).
The greylist file is specific to slackpkg+, see man slackpkgplus.conf
for a bit more details.
Bonus: Safe kernel upgrades
New kernels often have some kind of issues which may or may not affect a particular user, so it’s nice to be able to use an older kernel in case new version doesn’t work well. This is of greater importance if you use a rolling version like Slackware-current (might be done out of a necessity rather than a desire to use a bleeding edge and deal with its problems).
Slackware-current now makes it easy to install a new kernel without removing the old one. The old way required a procedure like this one (possibly as a script):
slackpkg download kernel
for f in System.map config vmlinuz vmlinuz-generic; do cp -d /boot/$f /boot/$f.old; done
find /var/cache/packages/slackware64/ -name 'kernel-*.txz' -exec installpkg {} \; -delete
touch /boot/have-old
# remove old kernel packages and a marker after testing new kernel
slackpkg remove kernel
rm /boot/have-old
Where /boot/have-old indicates presence of the old kernel to GRUB’s
configuration. This also could require blacklisting kernel packages because
slackpkg doesn’t like when several versions of the same package are
installed at the same time.
New way is much simpler:
make-kernel-backup slackpkg upgrade kernel # remove old kernel package after testing new kernel slackpkg remove kernel-backup
No need to manage a marker manually, /boot/vmlinuz-backup exists only when a
backup kernel is present.
The only downside I found is that make-kernel-backup doesn’t preserve kernel
sources/headers which can be a problem in certain cases (e.g., when you need
to build kernel modules after making a backup and upgrading, but before
rebooting), but it mostly worked fine for me so far.
There is much more to it: initrd is now generated automatically on kernel
installation with /etc/default/geninitrd configuring finer details of the
behaviour. I don’t use an initrd for the lack of a need for it, but still have
it generated in case I’ll have to boot on a different device where it may be
necessary (had to deal with this situation in the past). There is also no
kernel-huge anymore, by the way.