Derived from linuxpackages
If you ask a Slackware fan why she likes Slackware, she will probably mention Slackware package management as one of the features she likes. In what way does the Slackware package system differ from most other package managers? In one word: simplicity. In three articles I am going to cover some important aspects of Slackware package management. In this article I am going to show the anatomy of a Slackware packages. In part 2 and 3 I will cover the package tools and the process of creating a Slackware package.
Before getting into the details of Slackware packages I would
like to explain a few basic characteristics of Slackware packages. These days
most package managers are quite complex. For example, the most important
feature of many package managers is dependency handling. This means that if a
package requires other packages the package manager will take care of
installing them too. Most of the times this works, but dependencies can get a
bit annoying. For example, if you install software that is not in the main
distribution, version numbering conflicts can arise. The Slackware package
tools do not handle dependencies. The means to handle dependencies does not
exist in the
format of Slackware packages either. This can initially
scare away users, but it is (at least in my opinion) more flexible and
provides more freedom. Since there is no dependency management at all you are
Well, what is a Slackware package? A Slackware package is a tarball (an archive created with tar and compressed by gzip) which contains information about the package and an installation script. The information about a package is stored in two ways, first of all in the filename of the package, besides that the tarball contains a description file. Both will be covered later on. Last but not least a package contains an installation script. This script is automatically executed when installing or upgrading a package. Most packages only use an installation script for making symlinks. Correct Slackware packages do not have symlinks in the tarball, symlinks are set up using the install script.
The package filename provides some information about the package. This information is also used by the Slackware package tools, for example to decide whether some package is newer than the installed version. A package filename has the following syntax:
The different variables in a package filename are separated by by a
-. Naturally, it is not wise to use the separation character in one of
the variables. The filename is usually in lower case. The first variable
defines the name of the package, usually this is just the name of the
software. For example, for Mozilla this is
second field determines which version of the software the package provides.
This is usually used to determine when to upgrade a package and when not. The
third field specifies the architecture of the package. Nowadays the official
Slackware distribution only supports x86 machines. Up to Slackware Linux 9.0
packages were compiled with
, so the name of
this variable is usually
. Starting with
Slackware-Current after Slackware 9.0 support for 386 machines is dropped due
to some glibc issues. So new
-current packages are compiled with
gcc parameter. So, the architecture
in Slackware-Current. Last but not least
the revision number is specified. This is used when a newer version of a
package is released, but the package is still at the same version. Usually
this parameter is
and increases after revisions.
More information about the package is in the
/install/slack-desc file in the package tarball. This file
contains the package description which is shown during the installation of a
package. If you have ever installed Slackware you have probably noticed these
descriptions during the installation. Basically this file just contains the
description on multiple lines behind a
name: part on each line. I will
discuss the slack-desc file in detail in the article about creating a
Until we discuss package creation there is not much to say
about the install script. There are a few things you should be aware of.
First of all the script is in the
/install/doinst.sh file. The
second thing I should notice is that, though symlinks need to be created by
the install script, you do not have to write the symlink (
lines manually. The
makepkg script can take care of this.
Here are the native package management tools provided with a default
Slackware install. If you work solely with Slackware
these will provide everything you need to install, uninstall, and view
slackware packages. More information can be found at
One of the most important package tools is
installpkg. As the name suggests it allows you to install a
Slackware package. The basic syntax is
, for example
. It is no problem to
. However, just specifying will not word with
A good package system also allows you to remove packages.
Slackware has a package database in
directory contains one file per installed package in the following form:
programname-version-platform-revision. Each file contains
information about the package it represents. Each file also contains a file
removepkg uses these lists to remove files.
For a nice graphical text front-end to both
removepkg simply run
pkgtool. If you want to install a package then navigate to the
directory which the package is located, run
pgktool, and select
Install packages from current directory This will install all
.tgz files in this directory to your machine. Keep in mind
that once they are installed you do not need the
anymore and they can either be archived or deleted. I recommend having a
special folder in your home directory just for installing packages and
another directory for already installed packages. But that part of the
process is yours to decide how to handle.
Often you may need to install programs which are not in the
native Slackware package format of
.tgz but rather in
.tar.gz. Ninety percent of the time the way in which you would
install this package by hand would be:
$ cd package_to_install $ ./configure $ make # "su -" to root # make install # or simply, $ sudo make install # that is if you utilize the great sudo package
Doing this will install the package to your machine but not to the slackware package database. Therefore removepkg will not work if you ever need to uninstall the program. This can be an issue as many programs never provide a method to uninstall them at a later date and the administrator of the machine has to hunt down files and remove them manually. Not an ideal situation to say the least.
You can attain the latest version of checkinstall from http://proyectos.glo.org.mx/checkinstall/.
This program will convert source
.tar.gz files to a
Slackware, Debian, or RPM package at the
stage. So once you have downloaded a
tar.gz file (or any source
file for that matter) and have successfully resolved any dependencies you can
run this file, follow the prompts and create a slackware package which gets
For example to install
$ tar xzvf abc.tar.gz $ cd abc $ ./configure $ make # if the prior make command completes without any errors then su to root # or use a properly configured sudoers file like I do. $ sudo checkinstall
Follow all the prompts (like entering in a description) and this will
create the slack package and install it. It will also leave a
.tgz file behind if you need to reinstall it.
Swaret can be found at http://www.swaret.org/ and is by far one of the easiest way to maintain official slackware packages on your Slack box. Keep in mind that this program will only work with official slackware releases though. With Swaret you can effectively upgrade your Slackware box from 9.1 to current, install single packages, and search the slackware package repository. And in true Slack fashion you do all this from the command line.
Note that you can also update the kernel with swaret but I don't personally recommend it. Also keep in mind that swaret suffers from the exact same issues that any dependency checking software does, eventually you may break some packages, dependencies may not be correct, or the most recent version interferes with other software on your machine. But that being said, I've found it to be an excellent tool for upgrading KDE and other complex packages with many dependencies.
One thing you will want to do when you install swaret is change the
/etc/swaret.conf file so that you can update swaret with swaret
(remove swaret from EXCLUDE). This is due to the fact that swaret is
constantly evolving and running an old version could cause headaches later
on. Next set up the version to be
current in the VERSION area. Other
changes like proxy settings can be tweaked in this file if need be.
There are four basic usages for swaret, you will need to either be root or use sudo to act as root. For more information and many more uses of this slick program the swaret home page has an extensive list to reference in the how-to section.
This will update the package list that swaret uses to be the
most recent list. Definitely run this first thing after installing it and
perhaps weekly after that (the equivalent in Debian would be
update). The package list can be updated with:
# swaret --update
This will list if the package is available and if it is
installed or not. Before searching all of creation for a package on the
Internet try this command to see if you either already have it or can install
it easily with swaret. Searching is done with the
parameter, for example:
# swaret --search kde
You can install new packages and patch already installed packages with swaret. The following example would install xcdroast:
# swaret --install xcdroast
And this command a patch:
# swaret --install openssh -p
The following command will upgrade all packages to the most current ones in the tree that is used:
# swaret --upgrade
This will upgrade only KDE (a real pain to do by hand if you have ever had to do it):
# swaret --upgrade kde