Slackware Package Updates: Match the Branch, Verify the Transaction
Use Slackware's pkgtools and slackpkg deliberately: choose the correct mirror, inspect changelogs, preserve local packages, and plan recovery before upgrades.
Slackware’s package workflow is intentionally transparent, but transparency shifts work to the administrator. The core pkgtools commands install, upgrade, remove, inspect, and create Slackware packages; slackpkg automates retrieval and maintenance against official mirrors. The standard workflow does not promise that every dependency will be discovered and resolved automatically. Before adding software, the operator must understand the package’s dependencies, source, release branch, and lifecycle.
That model can make a system easier to audit because the installed package database is visible, but it does not make an arbitrary package safe. A SlackBuild, locally built package, or third-party repository remains code and supply-chain input that must be reviewed.
Keep the mirror on the intended branch
Before refreshing package lists, inspect /etc/slackpkg/mirrors and enable exactly one mirror for the correct release and architecture. A stable release and -current are different update streams: Slackware documentation describes -current as the development branch for a future release. Accidentally selecting it when you intended stable is not an ordinary mirror change; it changes the package stream and upgrade expectations.
For an installed system, establish the current state before a transaction. Keep a backup of critical configuration and data, read the applicable ChangeLog, check Slackware’s official release notes, and confirm enough free space in /, /var, and /boot. If the machine is important, test the same operation on a clone or snapshot first. A bootable recovery environment is especially important before replacing kernel or boot-related packages.
Understand the tools before running them
The included pkgtools provides tools such as installpkg, upgradepkg, removepkg, explodepkg, makepkg, and the interactive pkgtool. slackpkg adds mirror-backed package-list and upgrade workflows for official Slackware repositories. The package database and logs under /var/log/packages and /var/log/removed-packages help reconstruct what the native tools installed or removed; they are not a substitute for configuration backups or a record of every manual file copied into the system.
A careful maintenance session commonly starts by reviewing the mirror and GPG setup, updating the package metadata, and inspecting the changelog. The exact order and available subcommands can differ between Slackware releases and slackpkg versions, so check the local man pages and current SlackDocs before applying changes. A conservative command outline is:
# Run as root only after confirming /etc/slackpkg/mirrors is correct.
slackpkg update gpg
slackpkg update
slackpkg show-changelogThe first command refreshes the package-signing key data used by slackpkg; it is not a reason to accept an unexpected fingerprint without checking project guidance. Read the output and compare package changes to the correct branch’s ChangeLog before deciding what to install. For an ordinary system update, Slackware’s documentation describes install-new and upgrade-all as separate actions: new packages and package upgrades are not the same operation. Follow the sequence recommended for the release you are maintaining and review the proposed list before confirming.
slackpkg install-new
slackpkg upgrade-allThese are state-changing operations. Do not paste them into an unattended script until you have tested the workflow, reviewed prompts and configuration-file handling, and designed a recovery path. Avoid clean-system as routine cleanup: it can remove packages not recognized as part of the selected official series, including software you intentionally installed from another source. Review its proposed removals manually and preserve an inventory first.
Treat non-official software as a separate inventory
The official Slackware package set and third-party packages do not have the same ownership or update path. slackpkg is documented for official Slackware packages; community tools may extend it, but that introduces another repository and trust decision. If you compile software yourself, package it with a trackable package workflow instead of scattering files with an unrecorded make install. Record the source revision, build script, dependency assumptions, patch set, package checksum, and removal/upgrade procedure.
Do not assume package names or dependency relations from another distribution translate directly. RPM, DEB, and Arch packages are built against different filesystem layouts, library versions, maintainer scripts, and package databases. Installing one on Slackware outside an intentional compatibility environment can bypass the system’s package record and make later recovery harder.
Verify the system after the upgrade
Review package-manager output and logs, compare key configuration files, and check whether a kernel or initrd change requires bootloader maintenance under the installed setup. Reboot only when a suitable maintenance window and console recovery path exist; after boot, verify the running kernel, storage mounts, networking, services, and any workloads that depend on changed libraries. Keep the pre-upgrade snapshot or backup until those checks pass.
Slackware does not remove operational responsibility; it makes that responsibility visible. Matching the repository to the intended release, reviewing updates before applying them, tracking local software, and validating the post-reboot system turns a deliberately simple package toolkit into a controlled maintenance process.
Related:
- APT, DNF, and Pacman Compared: Package Management Across Linux Distributions
- How to Set Up Automatic Security Updates on Linux
Sources: