Author: Mayank Sharma
A Slackware package is a simple gzipped tarball of the form name-version-architecture-revision.tgz, for example, php-5.1.6-i486-2.tgz. When you uncompress and extract the contents of this tarball with tar -xvf php-5.1.6-i486-2.tgz, you get three directories, etc, usr, and install. The install directory contains a do-inst.sh script that, in essence, helps Slackware assimilate the contents of the unzipped etc and usr directory into the /etc and /usr directories under the root directory.
Installation on Slackware might sound plain and simple, but it really isn’t. Sure installing stand-alone applications isn’t an issue. But when it comes to installing applications that depend on other programs and libraries, the Slackware package management tools fall flat on their face.
Unlike packages made for repository based solutions, like Debian’s apt-get and Fedora’s yum, Slackware packages were not designed to be dependency-aware — and hardcore Slackware users would have it no other way. Installing dependencies by hand does have an advantage. It allows an administrator to remain in control of the libraries and programs installed on the system.
But being one of the oldest distributions has its advantages. Thanks to its faithful bunch of developers, Slackware has perhaps the largest collection of package management tools. Let’s look at some of them.
The venerable package tools
Slackware has a bunch of packaging tools that are as old as the distribution they support. Up front is the pkgtool utility that brings up a ncurses menu driven interface. With this tool you can install packages from the current directory or from another one. The tool is also aware of all the installed applications and can be used to remove several at one go. You can also view an application’s brief description and a complete list of files contained within any installed application.
Apart from pkgtool, Slackware has tools that will help you install, remove, and upgrade packages. The installpkg, removepkg, and upgradepkg utilities all take the name of an application as an argument and install, remove, or upgrade them, respectively.
You can also use the -warn option with the installpkg and removepkg commands. Instead of installing an application, this switch will simply print a list of files and directories that would be overwritten or removed if you install a particular package.
Want to know what a package will install before you pull the trigger? Use the explodepkg command to uncompress the tarball into the current directory and view its contents.
Installing non-slackware packages
Despite Slackware’s longevity, many application developers don’t supply a Slackware package. In that case you have two options, either build the application from source or use its RPM package if it’s available. To make use of an RPM package it has to be first converted into Slackware’s package format. This can be done using the rpm2targz and rpm2tgz tools. I successfully converted RPMs of several simple applications like that of Joe Text Editor, into tgz and installed and removed them without any issues.
If you decide to install from the source, you should do so through the CheckInstall tool, which itself is available as an easily installable Slackware package. Installing an application from source involves running the ./configure, make and make install commands that configures, compiles, and installs the application.
CheckInstall kicks in just before make install and learns everything the new application will add to the system. It then simply creates the Slackware package. We’ve written about CheckInstall in our CLI Magic series.
Repository-based tools
The biggest drawback of Slackware’s pkgtool is that it can only install packages available locally on the machine. This is where the Slackpkg tool comes into play. Slackpkg is designed for installing or upgrading packages through network. It works on the principles of online repositories, much like Debian’s APT. The tool gets package information from one of the official Slackware mirrors. You can use this information to search for packages and automatically download and install them.
Slackpkg isn’t installed by default, but is available in the extras/ directory on the second Slackware installation CD-ROM and can be easily installed using installpkg. Before the tool can be used, you need to edit the /etc/slackpkg/mirrors file and select one mirror by uncommenting its corresponding location.
After selecting the mirror, the slackpkg update command will download some important files from the mirrors, like the GPG key, which will help verify the authenticity of the packages. Once the tool has updated itself, it can be used to manage packages. Once a package has been retrieved from the online repository, in the background, Slackpkg uses Slackware’s installpkg to install them, along with the removepkg and upgradepkg tools to remove packages and install updates.
The tool puts Slackware on par with other modern distributions that can be completely installed and updated over the network. But it still has some rough edges. As we’ve mentioned in our Slackware 11.0 review, the tool’s search feature can sometimes return strange results.
Tools that resolve dependencies
All the tools that we’ve covered until now are incapable of resolving dependencies. This is a big turnoff for many desktop users. Just blaming the tools wouldn’t be appropriate. Like I’ve said earlier Slackware’s package format itself isn’t designed to be dependency aware. This led several Slackware users to design a new format, called the Extended TGZ. Packages in the extended TGZ format contain information about the package’s dependencies.
Third-party Slackware packages, aware of dependencies, are maintained at LinuxPackages.net and Slacky.it. These resources have active communities and between them, you’ll find the latest versions of most of the applications you need.
But the packages themselves can’t resolve dependencies, and neither can Slackware’s pkgtool or slackpkg. This paves the way for the Swaret and Slapt-get tools.
Swaret is probably the most popular Slackware package management application. Like Slackpkg, it’s designed to install, upgrade packages over the Internet and it can grab packages from the official repository. Furthermore, with swaret you can grab packages in third-party repositories like LinuxPackages.net. Swaret is also capable of installing missing libraries that an application depends upon.
After grabbing and installing swaret’s TGZ, rename its sample configuration file to /etc/swaret.conf and edit to select mirrors and other options, like its local tgz store. Unlike upgrades with the upgradepkg tool, swaret can backup a package that its upgrading and can rollback to this older version. You can script swaret to automatically update your Slackware distribution when a new version is released.
But if you want true dependency resolution, there’s no better tool than slapt-get. It works with multiple repositories and can resolve both libraries and application dependencies. I prefer slapt-get to swaret, since it has all of swaret’s features, and its options are very similar to apt-get, and is scriptable too. Like slackpkg, slapt-get uses Slackware’s native package management tools, installpkg, removepkg, and upgradepkg for managing packages. Slapt-get also has lots of usage-related documentation.
Portage for Slackware
The Gentoo Linux distribution is best known for its Portage package management system. Portage is a collection of build scripts that is used by Gentoo’s emerge utility to configure, compile and install a package. The system also provides for dependency resolution. If you’d like to have a system like Portage on Slackware, there are two options: Emerde and Portpkg.
Emerde syncs with Gentoo’s Portage tree, downloads the necessary build scripts, and installs them on Slackware. Emerde is still in beta and its developers advise installing it on a minimalistic Slackware installation to avoid possible conflicts with packages. The application can also be used to install Slackware packages directly.
Another approach to bring portage-like functionality to Slackware is Portpkg. Instead of using Gentoo’s portage, Portpkg uses Slackware’s own build file, SlackBuild. Portpkg has been built from the ground up to custom fit Slackware and can be used along-side swaret and slapt-get to keep the system updated, without causing any package conflicts.
Between the two systems, Portpkg is the more comfortable one for new users since its similar in usage to Slackware’s installpkg tool. Since Emerde syncs with the online repositories, it’s not a viable option for users with slow Internet connections. On the other hand, don’t expect Portpkg to have build files for every application out there.
Conclusion
Slackware is designed for users who prefer to be in complete control of their system. They swear by Slackware’s package management system and will have it no other way. However, another other group of users, spoiled by the one-click installation systems of newer distributions, fail to understand Slackware’s lack of dependency resolution.
Patrick Volkerding, founder, maintainer, and developer of Slackware must be credited for making provisions for automatic dependency resolution for those who choose to do so. And applications like swaret and slapt-get take full benefit of this. On the other hand, by adopting source-based installation methods from other distributions, upcoming tools like Emerde and Portpkg might just satisfy both old and new users.
