Home Learn Linux Linux Tutorials Intro to Slackware Package Management

Intro to Slackware Package Management

Many users decide to use Linux based operating systems because of the freedoms they enjoy, included in the list is the freedom to choose the right tool for the job. The Slackware package management schema is a model for displaying the choices that are available to the users. When maintaining a server or even a personal system a certain amount of control must be given to the administrator, the control and simplicity of Slackware package management is what may in fact make you want to try Slackware.

Brief Explanation of Slackware Packages

In terms of security and accountability Slackware is excellent because it beings you software in the condition that the authors intended. What this means is that the Slackware community does not modify the source or add and remove functions from software beyond the author's design. All packages are built using the original source code in which only official patches are applied, the only modifications that are made for the packages are adding .desktop files (executables for windows managers) and running installed applications/scripts to update application, font or icon caches to include the newly installed files.

Other distributions such as debian and redhat choose to modify the original source code with their own revisions prior to distributions, this can add additional functionality but in some cases such as the debian OpenSSL packages ( it can result exploits that only effect your distribution which can remain unseen for some time because the original authors (those who know the apps best) were not responsible for the changes or aware of the changes. This additional liability is something that doen't want hanging over your head when running a production system which requires heightened security and uptime, with Slackware these issues cannot happen all code that is used has been developed by those who know the functionality of the applications best, namely the original authors.

The Slackware packages can be found with any of the following extensions:

  • tgz - Slackware package archive compressed using gzip
  • tbz - Slackware package archive compressed using bzip2
  • tlz - Slackware package archive compressed using lzma
  • txz - Slackware package archive compressed using xz

Currently the two most commonly used formats are tgz and txz. txz is the current standard for official packages because of the increase compression rate, this change has allowed the development team to reduce the filesize in installation packages which in turn reduced the space requirements for the installation DVD, leaving additional space for new apps or documentation to be added in the same space as before. The tgz format has a less impressive compression rate but it is sufficient for packages that you build on your system since on most systems disk space is abundant.

Dependency Tracking

One of the major complaints by new users is the fact that Slackware does not automatically track dependencies and install dependencies when you install a file.  To many this may seem like a negative mark against Slackware, but I prefer to know exactly what is installed on my system and what it is for.

Why is Automatic Dependency Resolution is Bad Thing?

  • Lack of administrative control
  • It prompts for installation of packages that may have a bad security history, without manual research you would not be able to verify the security history of an installed package
  • It may install an app that conflicts with current installed apps which can break software components in your system.
  • If you may decide to recompile an app and remove certain functions, the removal of said functions may eliminate the need to have specific dependencies installed but with an auto-resolution system it will force those packages even though they are not needed

The official and many of the third-party package management tools in Slackware try to keep away from automatic dependency resolution so that the administrator is in full control of the system.

Installation and Package Management Tools

There are many package management tools for Linux both official and from third-parties, I will be discussing them below.

Official Tools

Included in the base installation of Slackware are two packages pkgtools and slackpkg.  pkgtools contains a set of application that are o be used for basic package management. slackpkg is a package manager and update tool for you to use with the official Slackware servers.

pkgtools contains the following executable applications, refer to the man pages on your system for more detailed information including options and syntax.

  • installpkg - This application is used to install a new package
  • removepkg -This application is used to remove a package from your system
  • upgradepkg - upgradepkg upgrades a Slackware package from an older version to a newer one.¬† It does this by INSTALLING the new package onto the system, and then REMOVING any files from the old package that aren't in the new package (taken from the man pages)
  • explodepkg - This tool uncompresses and untar a Slackware package into your current directory.
  • pkgtool - pkgtool is a menu-driven package maintenance tool provided with the Slackware Linux distribution.¬† It allows the user to install, remove, or view software packages¬† through an interactive system.¬† Pkgtool can also be used to re-run the menu-driven scripts normally executed at the end of a Slackware installation.¬† This is useful for doing basic reconfiguration (like changing the mouse type). (taken from the man pages)
  • makepkg - This application is used to create a new Slackware package from the contents of your current directory.

slackpkg is to be used to installed official slackware packages from the official Slackware servers and to manage updates and upgrades, this tools is very useful for keeping a system up-to-date and for doing a distribution version upgrade without having to do a reinstall or having to download and burn a disk.


Unofficial Tools

The unofficial tools are tools that were made by third parties which are not officially supported by Slackware.  These tools can be broken into two groups package retrieval and package building. The package retrieval tools have a functionality which is similar to YAST, yum, apt-get, urpmi and various tools which are used in other distributions.  These package retrieval tools call to specific package repositories which have been set by the user and allow the user to search the repositories and download and install pre-configured packages. In contrast the package building tools are somewhat similar to the package retrieval tools but rather than downloading a pre-build package they retrieve a build script (which can be customized and the subsequent source code allowing the user to custom compile an application for their system and their needs, once the application has been compiled the scripts pass the proper instructions to utilize the resulting binaries and build a Slackware formatted package that properly interacts with the Slackware package management tools. The best comparison for package building tools is to compare them to the portage system that is used in the BSD Operating Systems.

Listed below are the Unofficial tools and a brief explanation of their functionality.

  • 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.
  • sbopkg¬† - This tool syncs with the 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. If you choose to use a third party tool, this is the one I recommend; it has the highest probability or package stability and allows you to customize your packages.

Unofficial Sites/Repositories

  • ‚Äì This site holds community submitted builds scripts to easily build Slackware packages from the source code of various applications.
  • ‚Äì This is a repository of pre-built packages.
  • - This is a repository of pre-built packages.
  • alienBOB's repo ( ‚Äì First of alienBOB is able to do things that others can‚Äôt, so I trust his work immensely. His site contains pre-built packages and the associates build scripts use d to build them, so you can use it to download packages or to get stable build scripts and build the packages to fit your needs.

Please add repositories and sites that I missed in  your comments.

Installation Methods

Now because of the quality of various tools you have options for various functionality when it comes to package management and installations. The main three methods of installation are listed below:

  • Install from a pre-built package
  • Compile the app yourself from the source code, This is ill advised in it‚Äôs standard meaning, I will discuss this later.
  • Build a custom package from a build/slackbuild script

Install from a Pre-built Package

To install Slackware from a pre-built package you can use installpkg, upgradepkg, swaret or slapt get. This is very simple, in swaret or slapt-get you only need to choose the package and select to install it. To install a package using the official tools you only need to call the program and use the package name as the argument, (example.. installpkg wine-2.5.6-x86.tgz).

Compile the App from the Source Code

I know that many people have grown accustomed to this method over time, but it is not preferred in Slackware, instead to document your actions and avoid replication of efforts it is advisable to build a slackbuild script, believe me this will save you some time and effort in the future.

Build a Custom Package from a Build/slackbuild Script

This is the true magic in Slackware, every official package that you receive has a slackbuild file, in the source directory on the Slackware disk you will find the slackbuild files and source code for every package. This availability in the source directory allows you to view all options/modifications that were done to a package and if you need you can modify the script and arguments to fit your needs. Once the script has been run and the package has been built you then have a redistributable package for the specified application that fits your needs.

The script repository houses user submitted scripts for building stable applications for Slackware that have been tested on various architectures by extremely knowledgeable members of the Slackware community. Included in the slackbuild archive are the build script, license information, .desktop files (if needed), icons, and a .info file that tell you the version, source download location, md5sum, supported architectures and the author of the script. There is also a mailing list and an irc channel available if you have questions or experience problems.

Now for an example of how to build a package from a slackbuild, I will use audacity as an example .

  1. Find the app on, for audacity the page is
  2. Read the description to see what options are available and what dependencies are needed.
  3. Download the slackbuild file/archive to your computer.
  4. Extract the archive using tar or your preferred archive management tool, to extract the archive using tar you would type “tar xvf audacity.tar.gz”, this will extract the contents to a directory within your current directory named audacity.
  5. Go into the newly created directory.
  6. Download the source download that is listed on the website, a clean method is to use wget, for example you can type “wget –c”, the –c option is to make it continuous so that if you loose a connection you can restart from the last point in the download.
  7. Verify the md5sum of the downloaded source archive, to do it with this archive you would run “md5sum audacity-minsrc-1.3.7.tar.bz2”, if the checksum does not match the one on the website then your download was corrupt and needs to be downloaded again.
  8. Open the .Slackbuild file with a text editor.
    1. Modify the arch line (ARCH=${ARCH:-i486}) to reflect your system’s architecture, this can be pulled by running uname –a in the terminal.
    2. If you need you can go to the configure section to add or remove compile time options.
  9. Save and close the document.
  10. As root run the slackbuild file, in this case you would run “sh audacity.SlackBuild”.
  11. When the build and package process it complete the location of the resulting package will be announced, you will only need to install the package after this. has a howto page that can help you also (
Also if you can build a program from source then it is advisable to make a build script using the examples from around the compile operations, this will allow you to add documentation and save your build actions for future use.

Package Tracking

When using Slackware you have the ability to track the installation date, installed files, and package description of all packages that are installed on your system, This tracking is done within the /var/log/packages directory, this directory contains a single text file for each installed application, the file contains the package description and list of installed files/directories from the current package. You can easily view the list of files within the /var/log/packages directory and sort by name, creation date or whatever additional criteria you use. 

For some examples of the usability of the /var/log/packages directory I will show you the following. If you are looking to see what package installed a specific file to your computer, let say the file is /sbin/iptables, you can run the commands “cd /var/log/packages;grep /sbin/iptables *” this will display all files within the current directory that contain the exact phrase that was called by grep. If you want to review the installed files for a package to find all files that were installed in the /bin directory, let say we are looking at the pkgtools package, you can run the command “cat /var/log/package/pkgtools-13.0-noarch-3.txt|grep /bin/”.

In a similar fashion Slackware moves the text files from /var/log/packages to /var/log/removed-packages when you remove a package from your system, this makes it easier to have adequate tracking of what you have installed and what you removed and when each action was taken, this will help you greatly if you are wanting to replicate the list of installed packages from one server to another, you can easily write a script to compare the output of the folders on both systems and output a resulting file of non-matching packages that you can later use in a script for automatic installation..

That is all that I can think of right now on this subject. I am sure that the readers will have much to add to detail additional options and functionality, so please add whatever you like in the comments.

I know that I did not cover any specific tool in-depth but if you would like an in-depth explanation, please post a request in the forum and I will gladly write up more detailed responses.



Subscribe to Comments Feed
  • Brian Said:

    I just read about Slackware Current at What is Slackware Current? How do you do that? What are your thoughts on it? Thank you.

  • Matt Said:

    While I'm sure you have found the answer you were looking for by now, I'll answer for anyone else who might come across your question. Slackware-current is the Testing version of Slackware, while the releases (13.0, 13.37, 14.0, etc) are the Stable versions. As expected, Slackware-current has packages which are more up to date but the "kinks" won't have been worked out as would be expected in a stable release. As a result, you would not want to use Slackware-current in an environment where stability is key, but it might be more "fun" on a desktop if you enjoy troubleshooting on occasion. By running Current you're pretty much volunteering to be one of Pat Volkerding's guinea pigs. The best way to get Slackware-current would be to use current packages during your initial install, although I do suppose you could get away with jumping to current from the most recent release version. Next, you would need to edit /etc/slackpkg/mirrors, jump down to "Slackware-current", and uncomment the mirror server closest to you. To keep Slackware-current up to date (which I will assume you would want to do if you're running current!), you'll need to run slackpkg. This is done by running the following commands from root: #slackpkg update #slackpkg install-new #slackpkg upgrade-all #slackpkg clean-system You have to be careful with that last command and make sure you've blacklisted all of your unofficial packages, as otherwise they may be removed if you aren't careful. Do this process every time you want to make sure your system is up-to-date. Personally, I prefer to run Stable. For me, the charm of Slackware is that I never have to worry whether it's going to work... it just does. Don't run Slackware-current if you want the "latest and greatest" -- for that I would personally suggest Arch, which is simple, rather reliable, and has far more packages. Instead, run Slackware-current if you already love Slackware, enjoy trying to solve the occasion problem that might arise, and want to help in making the next release of Slackware the best that it can possibly be.

  • Matt Said:

    Ugh... what happened to my paragraphs?!?

  • Jay Said:

    Serisouly? Automatic dependency resolution is a bad thing? This type of mindset will leave all linuces way behind the competition. How can a new user be expected to understand how dependencies work? How long do you think a new user would spend in the labyrinth of manual dep resolution?

  • Dan Said:

    The ignorance of the author is astounding. ** Lack of administrative control ** Dependencies are dependencies, whether you like it or not. If you need to install package "foo" and it depends on "libbar", you are going to have to install "libbar" whether you like it or not. Automating dependency management simply removes the burden from the administrator to hunt down and manually resolve the dependency on "libbar". Either way, the administrator decides whether or not "libbar" gets installed, knowing that if he/she doesn't install it, "foo" will not work. ** It prompts for installation of packages that may have a bad security history, without manual research you would not be able to verify the security history of an installed package ** Either way the administrator needs to decide how careful he/she wants to be about installing packages. Even without automatic dependency resolution, an administrator may install a package with a lousy security history. What's your point? ** It may install an app that conflicts with current installed apps which can break software components in your system. ** An automatic dependency resolver is much more likely to detect conflicts of this nature. ** If you may decide to recompile an app and remove certain functions, the removal of said functions may eliminate the need to have specific dependencies installed but with an auto-resolution system it will force those packages even though they are not needed ** A decent dependency resolver absolutely will detect that the package is no longer needed. For instance, on Gentoo "emerge --depclean" will find automatically find and remove any dependencies that are no longer needed. Heck, even a dumber package system like RPM will see that the dependency is no longer there an allow the admin to remove the unneeded package. What a bunch of malarkey.

  • Dimitris Said:

    Hi, I created this tool solves hands on building packages. Please try... Best regards, Dimitris

Who we are ?

The Linux Foundation is a non-profit consortium dedicated to the growth of Linux.

More About the foundation...

Frequent Questions

Join / Linux Training / Board