Third Party Package Managers

Purpose

The mere mention of third party package managers (such as slapt-get and swaret) often results in a quick admonishment from Slackware users, and unfortunately, the only reason given in most cases is something along the lines of "they'll break your system." This leaves users in a state of confusion, as the respective web sites of these third party tools tout them as an improvement. The purpose of this page is to explain why and how these tools will often result in system breakage.

Overview of Slackware's Native Package Tools

Slackware's native package management utilities (pkgtool(8), installpkg(8), removepkg(8), and upgradepkg(8)) do not support any form of dependency checking. A Slackware package is essentially a compressed tarball of the files associated with an application, a file containing a short description of the application (./install/slack-desc), and a script that performs some essential post-installation tasks (./install/doinst.sh). Installing a Slackware package simply copies those files to the filesystem and then executes the post-install script, while removing the package removes the files and reverses the post-install script. As result, there is no guarantee that libraries and other files needed by a particular package are already present on the system when that particular package is installed.

Overview of Selected Third Party Tools

As stated above, Slackware's native package management suite neither has nor supports dependency resolution. Because the third-party add-ons all use Slackware's native package tools, they are bound by this same limitation, at least to some extent, but some of them try to mitigate this in various ways; the following is an overview.

swaret

no longer a viable package management solution

slapt-get

Overview

Slapt-get makes use of additional files (slack-required, slack-suggests, slack-conflicts) inside a Slackware package. Essentially, if a package is listed in slack-required, then slapt-get will install or upgrade it first; if a package is listed in slack-conflicts, then slapt-get will remove it first; if a package is listed in slack-suggests, then slapt-get will offer to install it in addition to the packages noted in slack-required.

Potential Problems

Since official Slackware packages do not have the slack-required and other files needed for slapt-get to determine dependencies, it is not able to resolve dependencies for them. Therefore, slapt-get's perceived usefulness is in keeping unofficial third-party packages (or at least those which do contain the necessary files) up to date. See the discussion below for more information on unofficial third-party packages. Also, slapt-get, like swaret, will not "downgrade" a package to a previous version if it occurs in the upstream Slackware tree.

sbopkg

Overview

SBopkg is a tool for automating the download, compile and package build for SBo projects hosted in the SlackBuilds.org repository. SBo packages are reviewed by team members for completeness as well as applicability to each Slackware release. SBo package documentation includes information regarding dependencies.

sbotools

Overview

sbotools provides a ports-like interface to SlackBuilds.org. It consists of several commands, and a configuration file. It is written entirely in Perl and bundles a copy of the Sort::Versions module with itself for its own usage; this will not interfere with copies installed via the CPAN or SlackBuilds.org.

Third Party (Unofficial) Packages

This subject can elicit opinions just as strong as the topic of third-party package managers, and there are knowledgeable people on both sides of the issue. Third party packages can obviously present a security risk, as there's no way to know what's really in them, but for the average user, there are (amazingly enough) bigger concerns. On one hand, the user wants a package of some application that's not included with Slackware, but he doesn't want it to create other problems. Oftentimes, third party packages are not built on "clean" systems -- that is, the computer on which they're built has quite a few other non-official packages installed -- so the resulting package needs those other things to work properly. If the packager doesn't make note of all the different packages that this one depends on, the user installs it only to find that it still doesn't work. Even worse, those other dependencies are often not even necessary if the package is built on a clean system - if the other package had not been present, the new one obviously wouldn't have linked against it. Installing third party packages from two different packagers can cause problems. Package A might depend on Package B, which depends on Package C and optionally Package D. If the person who built Package B only linked it against Package C (not D), but the Package A expects Package B to have both Package C and Package D dependencies, then Package A may not work, even though you (think you) have everything it needs installed. Another frequent problem with third party packages is encountered by replacing stock (official) packages with unofficial ones. In addition to the library version issues mentioned in the swaret discussion, newer package versions often require newer versions of other packages, which might require newer versions of still other packages, and before you know it, you have replaced a sizable portion of the official Slackware packages. If/when something breaks, you will find it very difficult to find someone willing to help you, as there's no way to know how much effect the unofficial packages are having.

Slackware -current

Slackware -current is *not* a stable release of Slackware. It is intended for advanced users who are familiar with how Slackware works to test (and report success/failure, find and fix bugs, etcetera) the new packages leading to the next stable release of Slackware. Packages are constantly being added, removed, split up, merged, and otherwise mangled, and third party package managers (swaret/slapt-get/et al) should not be expected to know how to deal with this. If you use one of those tools while trying to run Slackware -current and you don't understand how they work and their limitations, you *will* break your system and you will *not* have much luck finding someone who is sympathetic. You have been warned.

You may be wondering why these tools have trouble with -current. I won't even attempt to detail all of the potential issues, but here are a couple: 1. When upgrading to -current with one of these tools, the package sets are upgraded in alphabetical order (and the packages therein also in alphabetical order). This means that a/bash will be upgraded before a/glibc-solibs. If bash has been recompiled against newer glibc, and you upgrade to that new version, it will promptly stop working due to the fact that the needed version of glibc has not been upgraded yet; at that point, you are stuck with a "chicken and egg" problem. 2. Third party package tools will not install *new* packages that have been added in Slackware -current. This is not a bug - it's a feature; if you purposefully didn't install something, then you don't want your automatic package updater reinstalling it. However, when a package depends on something else that has been added or split out of an existing package, and your add-on package manager upgrades the existing package but doesn't install the added one, then the (upgraded) existing package will not work any more.

Solutions and Suggestions

For upgrading to Slackware -current, there is only *one* supported method: UPGRADE.TXT -- you can find this file on any Slackware mirror. Note that this is also the only supported method to upgrade from one stable release of Slackware to another.

For keeping up to date on post-release patches added to a stable release of Slackware, you will *usually* be okay to use one of the third party package managers. You should still read the ChangeLog.txt before doing any upgrades, though, as new packages are occasionally added in /patches when circumstances require it.

For software not included in official Slackware, consider building it yourself or using a SlackBuild script from one of the projects which provides them.

One of the regular Slackware contributors, PiterPUNK, wrote and maintains a third-party package manager that minimizes all of the risks mentioned above. Slackpkg does not support downloading or installing unofficial packages, and it has provisions to install any added packages and uninstall any removed packages as well as the normal install/upgrade/remove routines.

Another third party package manager that promotes good practices is SlackRoll (see tutorial). Its philosophy is similar to that of Slackpkg but it is not included as part of Slackware. Programmed in Python, it is faster, has more features and detects more events from Slackware -current. However, the initial setup and workflow are a bit more complex.

See Also

• pkgtool(8) -- man 8 pkgtool
• installpkg(8) -- man 8 installpkg
• removepkg(8) -- man 8 removepkg
• upgradepkg(8) -- man 8 upgradepkg
• makepkg(8) -- man 8 makepkg
• explodepkg(8) -- man 8 explodepkg

TODO

• Add links to other wiki pages that are related to this topic (add to "See Also" above)
• Add hyperlinks to slapt-get, swaret, and other projects mentioned on this page
• Others?