Slackware Package Management
Published: 2022-01-13 | Last Updated: 2022-01-13 | ~16 Minute Read
Table of Contents
- Introduction
- Package management methodology
- Which package needs what
- Package installation overview
- Dependencies in more depth
- Slackware package management
- Benefits of Slackware package management
- Areas of opportunity
- Unofficial Slackware package managers
- Conclusion
Introduction
This is my attempt to go over Slackware package management in a way that can help newcomers to the distro understand it much faster. I have been using Slackware for about 10 years now, since version 13.37, and love it but I must admit I still don’t know everything there is to know about it. This however is not due to the complexity of the distro but in fact the opposite, it is so easy and simple to use that you don’t need to learn all the ins and outs of how it works to have a perfectly stable system running.
My gaps in knowledge originate from me being lazy and not because Slackware is so complex that even after ten years I still have not learned it all. I’m sure there are other users who, like me, after many years of using the distro are still not very familiar with some parts of the system.
If this is the case for “veteran” users of the distribution I can imagine why it must seem daunting for users that may be thinking about giving it a try for the first time.
Package management methodology
In case you need a quick refresher on package management, I have written about general package management here. I will be focusing on Slackware’s way of package management in this post.
Slackware states as part of its philosophy that it is:
A distribution that does not add layers of abstraction or complexity on top of existing solutions. For instance, Slackware package management is handled by simple scripts acting on compressed tarball package files (.tgz, .txz, *.tbz) and there is no dependency handling for package management.
This simple statement is one of the many features that make Slackware stand apart from other Linux distributions, however it is not as evil as it may seem at first sight to those more used to distributions that handle dependency resolution for them automagically.
In practical terms Slackware allows the system administrator to handle the installation of software on their system from A to Z. In other words if you want to install say the Firefox web browser you will have to not only worry about the Firefox program but all of the programs that it depends on. This is just an example and usually not the case for the Firefox web browser since it comes included in a full Slackware installation, however this applies for any program that you may wish to install and is not included as part of the Slackware “full installation” binaries provided in the Slackware repositories.
In practice if you wanted to install the discount program for example, which is not in the Slackware package repositories, then you would have worry about whether or not this package needs any additional software that it depends on to work properly. In case it does then you have to first install that software and then install the discount program. In this case the discount program does not have any dependencies that are not part of the “full installation” of Slackware.
Now let’s take a package like jitsi as an example, for this package you would have to install its dependency first openjdk7, but before that you’d have to install openjdk7’s dependency which is apache-ant. So effectively you would have to install three packages in the following order: apache-ant > openjdk7 > jitsi. Again this is considering that during the Slackware installation you selected “Full Installation” from the installer menu. So the full picture would be Slackware full installation > apache-ant > openjdk7 > jitsi.
In case you did not select the “full install” option then you may have to install additional packages before being able to successfully install jitsi or other programs.
Which package needs what?
The natural question that follows is “so how do I know what x program needs?” and this is where some users may feel overwhelmed and decide to look elsewhere for their distribution of choice. The answer largely depends on the package you’re trying to install and how its maintainers decide to publish this information. Usually information related to dependencies is either on the package official documentation or in the source bundle to compile the package.
In either case I like to look at the unofficial Slackware package script repository Slackbuilds. Slackbuilds is a community maintained project where several individuals with experience in building each of the software packages take it upon themselves to check what dependencies are required by a package and provide helpful bash scripts to install them.
Package installation overview
Before moving on, it is important to note a very key distinction in the way that Slackware (and Linux) expects you to install software. There are two main steps to install software, software compilation and software installation.
Software compilation
The compilation step is where code from programmers gets taken and converted into machine readable code.
Generally all systems need for software to be bundled into a language that the computer can understand so that the program may be executed and perform its job, this process is called software compilation because it’s performed by a software program called compiler. So just like Slackware all other systems need to take this step however in other systems the maintainers of the operating system choose to take away this step from the software installation process, by performing the compilation themselves, with the intention to ease the burden of system administration to the end user.
Software installation
The installation step is where the resulting files from the compilation step get written to disk in a way that is accessible to the system user for execution.
Many are used to clicking a file and having the operating system install the program. In a Windows OS for example you download a file with the .exe suffix and double click it and after a setup wizard you can click an icon and the program you wanted launches. Similarly on other Linux based systems like Ubuntu a user would run a command like sudo apt install firefox or select the program they wish to install from a GUI based software manager, click “Install” and they would be able to open their program after a few moments.
This method is not natively supported in Slackware due to its philosophy, by compiling the programs for the user other systems are abstracting away steps the user should be taking. This could also be seen as the OS getting in the way of the user which is something Slackware opposes.
Impact of abstracting the installation process
This decision from the maintainers means that the users of those systems do not get to see the compilation process of package installation and so they’re essentially only doing half of the installation process. Many users however believe that this is the full process and so when given the power to perform both steps are often overwhelmed because of the additional requirements.
This leaves the impression that Slackware is hard to use to users that come from systems where these steps are taken for them.
Dependencies in more depth
There is another important concept to understand before taking a look at installing packages and that is the type of dependency that a package needs. There are two types of package dependencies: run time and build time dependencies.
Build time dependencies
A build time dependency is software that is required during the compilation step of the package installation. This may be a software framework or other software that is used by the compiler to generate the machine readable code we spoke of earlier.
Run time dependencies
After the actual installation step of the installation process, when the program files become available to the user for execution, the software installed may use or need other software to successfully run on the system. This means that the software installed may have compiled successfully but fails to execute due to missing runtime dependencies.
Slackware package management
The Slackware documentation project already provides details on how Slackware manages packages, however I will summarize the main points here.
These system wide administration operations are meant to be done by a user with super user privileges like the root user for example. Slackware has two main tools for package management: pkgtools and slackpkg
pkgtools
The pkgtools program provides the following commands to the user for package management:
installpkg - Program used to install a new package. Usage example:
installpkg [options] <package_filename>
removepkg - Program used to remove a package from your system. Usage example:
removepkg [--copy] [--keep] [--preserve] [--skip-douninst] [--terse] [--warn] packagename ...
upgradepkg - Program used to upgrade a Slackware package from an older version to a newer one. Usage Example:
upgradepkg [options] <newpackage> ...
explodepkg - Program used to uncompress and untar a Slackware package into your current directory so the contents can be reviewed prior to installation.
explodepkg package_name [package_name2, ...]
pkgtool - Program used as a menu-driven package maintenance tool provided with the Slackware Linux distribution. Simply running the pkgtool command will bring up an ncurses interface:
makepkg - This application is used to create a new Slackware package from the contents of your current directory. Usage example:
makepkg package_name.tgz
Additionally pkgtools provides a handy database (plain text file) for users to see all of the packages that are installed on their system and all of the files that were installed by that package. This database is located in the following destinations depending on your slackpkg version (this changes depending on your Slackware version):
Slackware 14.2 / pkgtools-14.2-noarch-xx.txz:
- Installed packages:
/var/log/packages - Removed packages:
/var/log/removed-packages
Slackware 15.0 / pkgtools-15.0-noarch-xx.txz:
- Installed packages:
/var/lib/pkgtools - Removed packages:
/var/log/pkgtools
With this we can easily find which files where installed by the pkgtools program (as well as other handy information about the package) for example:
From the command line:
root@host:/var/log/packages# cat pkgtools-15.0-noarch-34 | head -30
PACKAGE NAME: pkgtools-15.0-noarch-34
COMPRESSED PACKAGE SIZE: 196K
UNCOMPRESSED PACKAGE SIZE: 400K
PACKAGE LOCATION: ./pkgtools-15.0-noarch-34.txz
PACKAGE DESCRIPTION:
pkgtools: pkgtools (The Slackware package maintenance system)
pkgtools:
pkgtools: This package contains utilities for handling Slackware packages.
pkgtools: Included are the command line utilities 'installpkg', 'removepkg',
pkgtools: 'makepkg', 'explodepkg', and 'upgradepkg' that install, remove,
pkgtools: build, examine, and upgrade software packages. Also included are
pkgtools: 'pkgtool', a menu based program for installing packages, removing
pkgtools: packages, or viewing the packages that are installed on the system,
pkgtools: 'pkgdiff', a utility for comparing two packages, documentation (man
pkgtools: pages), and a few other system admin scripts.
pkgtools:
FILE LIST:
./
install/
install/doinst.sh
install/slack-desc
sbin/
sbin/explodepkg
sbin/installpkg
sbin/makepkg
sbin/pkgdiff
sbin/pkgtool
sbin/removepkg
sbin/upgradepkg
usr/
Via the pkgtool interface:
slackpkg
Slackpkg is another tool provided by default in Slackware, it can do most of the operations that pkgtools does since it uses it in the background, but it provides additional functionality as well. From the man page:
SYNOPSIS
slackpkg [OPTIONS] {install|remove|search|upgrade|reinstall|blacklist} {PATTERN|FILE}
slackpkg [OPTIONS] {clean-system|upgrade-all|install-new}
slackpkg [OPTIONS] {search|file-search} {PATTERN|FILE}
slackpkg [OPTIONS] {generate-template|install-template|remove-template} TEMPLATENAME
slackpkg [OPTIONS] info PACKAGE
slackpkg [OPTIONS] update [gpg]
slackpkg [OPTIONS] {new-config|check-updates}
slackpkg [OPTIONS] help
With slackpkg you can keep your local packages up to date with the those on the official repositories that Slackware provides, this enables easy updating of the system for the core Slackware packages. In general the way to use slackpkg is the following:
Edit your /etc/slackpkg/mirrors file have a Slackware mirror selected
Run the following to sync the gpg key:
# slackpkg update gpg
Initialize / update the slackpkg database:
# slackpkg update
Install new packages:
# slackpkg install-new
Upgrade any packages that have new versions available:
# slackpkg upgrade-all
As a note when upgrading the kernel version on your system, you will be asked to run /sbin/lilo in order to update the proper kernel version that should be used at system boot. Make sure you do this in order to avoid issues on the next system boot.
Benefits of Slackware package management
This way of managing software provides various advantages both technical and non-technical, below are some that come to mind:
- System stability
- Less bloat
- Trusted/known software
- Ownership/control of the system
Areas of opportunity
Some users still consider this package management strategy less than ideal to manage their systems, below are some areas of opportunity that I have seen others mention:
- Time consuming
- Error prone
- Technical expertise required
Unofficial Slackware package managers
The community has created additional tools to ease package management in Slackware, these solve some of the potential problems presented earlier. With the use of these additional tools Slackware becomes very easy and simple to maintain. Some of these community created tools include (from the Slackware documentation):
swaret - This tool is designed to replicate the functionality of the Debian apt-get system, you identify the repositories you would like to use and it allows you to download and install packages from the specified location, this tool also attempts dependency resolution.
slapt-get - This tool is designed to replicate the functionality of the Debian apt-get system, you identify the repositories you would like to use and it allows you to download and install packages from the specified location(s).
sbopkg - This tool syncs with the slackbuilds.org build script repository, it is used to pull build scripts, upon choosing the scripts to build it allows you to choose the build order and also customize the scripts. Upon completion of the scripts it will allow you to build a Slackware package or to build and install the package.
slpkg is a powerful software package manager that installs, updates, and removes packages on Slackware based systems. It automatically computes dependencies and figures out what things should occur to install packages.
Conclusion
I hope this overview into how package management works in Slackware has provided some insight and clarity into the matter. Hopefully it is now clear why some Slackware users say that Slackware is actually easier to maintain than other distros that provide dependency resolution.