SlackRoll is a package or update manager for Slackware Linux. Part of this tutorial has been taken from its official webpage and FAQ. SlackRoll's defining points:

Its internal mechanism based on package states.
Like slackpkg, SlackRoll only works with official mirrors, meaning that to keep third party packages up to date you need to perform the task by hand (recommended practice, using SlackBuild scripts) or use a second different tool.
It does not try to compare package version numbers to decide if a package should be upgraded or not.
Partly as a consequence of the previous point, it has no known flaws detecting package updates (including reverts), new packages, removed packages, third party packages getting an official version and blacklisted packages (frozen in its terminology) being removed.
It has a broad range of operations and features.
It attempts to be fast. Most internal operations like listing available upgrades usually take less than one second on a modern computer.

Installation

Requirements

Python 2.4 or later (provided by package python starting with Slackware 10.1).
GnuPG (provided by package gnupg or gnupg2).
Vim (provided by package vim).
A pager which is less by default (provided by package less).

Procedure

Download the SlackRoll package from the project download page and install it in your system using installpkg.

Background Information

The majority of SlackRoll commands that receive a list of packages expect only the package names (foo as opposed to foo-1.1-i486-3.tgz). Some of them also allow using a specific version, but they are the exception.

SlackRoll creates a persistent database of packages in your hard drive. Each package is in one of several possible states. Part of the initial configuration consists in deciding which states some of your packages will have. There are two types of states: states to avoid (temporary states) and normal states. When the remote Slackware official tree is updated, SlackRoll may put some packages in temporary states. By upgrading, installing, removing and marking packages your objective is to correct those packages and put them in a normal state.

States to Avoid

New

New packages are packages present in the remote tree that weren't present before. You should decide if you want to install them or mark them as not installed.

Outdated

Outdated packages are present in your system, but the version you have does not match any relevant one in the remote tree. You should upgrade these packages.

Unavailable

Unavailable packages are packages present in your system. Previously, they probably existed in the remote tree, but now they do not seem to be available for downloading and installing. You should decide if you want to remove them or mark them as foreign.

Normal States

Installed

Installed packages are very common. They are present in your system and in the remote tree, and both versions match.

Not Installed

Not installed packages are also very common. They are present in the remote tree but not in your system. They can be downloaded and installed if you want.

Foreign

Foreign packages are packages present in your system but not in the remote tree. However, unlike unavailable packages, they are supposed to be present in your system. No package will enter this state automatically. Only the ones you mark. It's usually reserved for third party packages and packages you build yourself. It's worth noting that if a foreign package ever appears in the remote official tree, it will be marked as installed or, probably, outdated. Thus, SlackRoll will give priority to the new official package over yours. If you still want to use your own build, mark it as frozen.

Frozen

Frozen packages are present in your system and in the remote tree. Your version may or may not match the ones from the remote tree, but SlackRoll will not tell you they need to be upgraded. No package will enter this state automatically. It's usually reserved for packages that shouldn't be upgraded automatically or ever (aaa_elflibs, kernels, etc) and sometimes for customized versions of official packages. It's also worth mentioning that a frozen package will be moved to unavailable if it disappears from the remote tree. It that happens and you want to continue using it, you'll need to mark it as foreign.

Initial Configuration

Word of warning: it's highly recommended to do the initial configuration from an up-to-date and controlled system. This will avoid confusion and helps preventing mistakes setting the initial package states.

Preparing Your System

Choose a Slackware mirror for your Slackware version. Use the set-mirror operation to select one mirror. SlackRoll can work with stable trees as well as the current tree. Example:

 # slackroll set-mirror 'http://slackware.example.org/slackware-current/'

Do not forget to include the trailing slash in the mirror URL. Import, to your keyring, the GnuPG key used to sign the official Slackware packages. This key can be found in Slackware CDs and DVDs as the file GPG-KEY, and you can import the key to your keyring using the command gpg --import, but SlackRoll is able to download the key from the mirror and importing it automatically, if you trust the mirror.

 # slackroll import-key

Finally, retrieve the mirror information for the first time. This will download a few metadata files, and this is what you need to do when you're going to handle a new round of updates.

 # slackroll update

Going Over Package States for The First Time

When you run SlackRoll for the first times, it will put every remote package not present in your system in the state New. When your system is up to date and under control, you can blindly mark every new package as not installed with the following command:

 # slackroll new-not-installed

Any third party package present in your system will be put in the state Unavailable. When your system is up to date and under control you can blindly mark all unavailable packages as foreign. However, the number of foreign packages is usually not very high and forgetting to remove from your system a package that was removed from the remote tree is a common mistake. The Book of Best Practices would suggest that you review the list of unavailable packages once and carefully in order to detect packages that should not be present in your system. To print the list run:

 # slackroll list-unavailable

If you locate any package that needs to be removed, you can remove them using removepkg or the remove operation. The later has additional functionality so it's recommended:

 # slackroll remove foo bar

Now you can mark the rest as foreign packages.

 # slackroll unavailable-foreign

Finally, you probably want to mark some packages as frozen. It's usually a good idea to do this with aaa_elflibs, kernel packages and others.

 # slackroll frozen aaa_elflibs foo bar

Day to Day Usage

Apart from the operations listed here, you can run the help operation to get the full list of supported operations, along with a brief description of each one. A more detailed description can be found in the operations guide.

New Round of Updates

What to do when there is a new round of updates? The Book of Best Practices suggests taking care of different events in a specific order:

Updates to glibc-solibs, sed and pkgtools need to be handled first, in that order.
If there are new packages, handle them second.
Then, it's time to upgrade outdated packages.
If packages have been deleted from the remote tree, handle them last.

This is the correct order in 99% of the cases. SlackRoll will attempt to warn you and ask for confirmation if it detects you may be breaking this order. However, you have the last word on what to do, so proceed with caution and don't break your system.

First, update the remote mirror information with the update operation we mentioned before. New changelog entries will be saved to your hard drive. It's recommended that you take a look at the changelog at this point, using the changelog operation. Then, get an overview of the events using the list-transient operation, which will list the new, outdated and unavailable packages along with a big fat warning message if activity in key system packages is detected.

The best way to deal with glibc-solibs, sed and pkgtool updates is to use the upgrade-key-packages operation.

 # slackroll upgrade-key-packages

You could also use the install operation. Despite its name, it can be used to both install and upgrade individual packages. Let's suppose packages glibc-solibs and sed where updated:

 # slackroll install glibc-solibs sed

The install operation is one of the few operations allowing you to pass specific package versions. It will proceed in the order you indicate, so remember to give the packages in the correct order if you use this method.

Second, you should handle new packages. You can clearly get a list of new packages with the list-new operation. New packages can be installed with the install operation as we just showed. When installing a remote package, SlackRoll will give you the opportunity of selecting the version to install if there are several available in the remote tree. Or, if you are not interested in installing a new package, mark it as not installed:

 # slackroll not-installed foo bar

If the package names are not enough for you to decide if you want to install it or not, you can always use the info operation and SlackRoll will download and display the package info file (small txt files in the remote tree). And, of course, be carefull with new libraries as they may have been included to extend the functionality of an existing package you may have installed.

The third step is taking care of outdated packages. For that, a few operations are available. list-upgrades lets you see a summary of the available upgrades. You can download and install them with upgrade or download them with download-upgrades or even print their URLs with urls-upgrades.

And, finally, review the list of unavailable packages. Be careful with unavailable packages. Sometimes you install a foreign package but forget to mark it as such in SlackRoll. To avoid that problem, it's better to install them with the install-foreign operation. Individual unavailable packages can be removed with the remove operation as we showed before, and also all of them at the same time with the remove-unavailable operation.

Installing and Removing Individual Packages

There are a few operations related to installing and getting some information about individual packages. The most common ones are install to upgrade or install packages, info to maybe download and display package info files, urls to get a list of URLs and remove to remove individual packages.

Operations that install packages let you manage .new files after the installation is completed, in a similar way to slackpkg. You can view the differences between the .new file and its counterparts with vimdiff (which provides a nice and colorized way of spotting the differences and maybe porting the old configuration to the new file), you can overwrite the old file with the .new file, delete the .new file directly, etc.

Additionally, removal operations also track pairs of .new files and give you the opportunity of deleting configuration files that have been left behind. You are not forced to remove the files left behind, of course.

Upgrade operations will perform both tasks. First, they will let you review the .new files and then they will give you the opportunity of deleting obsolete configuration files left behind.

While using vimdiff, turning off syntax highlighting is recommended. Vim uses colors to highlight file differences and those can interfere with syntax highlighting colors, making text invisible or hard to read. Syntax highlighting can be turned off temporarily by using ":syntax off" in command mode, or you can disable it permanently putting "syntax off" in your ~/.vimrc file (noting that usually you run SlackRoll as the superuser).

Managing Customized Versions of Official Packages

There are at least three ways of dealing with customized versions of official packages. These are custom versions or compilations of packages present in the remote official tree. They are normally used to add or remove features, or activate or apply patches that are disabled by default. For example, if you want to activate the freetype bytecode interpreter, you need to rebuild that package.

The simplest way of dealing with these packages is to give them the same name and version as the official packages. When they are upgraded in the remote tree, however, SlackRoll will want to upgrade them. You can mark them as frozen before upgrading and only unfreeze them after you have rebuilt the new version, if you want to avoid SlackRoll replacing them with the new official version.

Second, you can give them the same name and version as the official package, but keep them frozen all the time. How would you know then if they need to be rebuilt? With the list-outdated-frozen operation. Take into account the information given by list-outdated-frozen is not reflected by any other command. Specifically, it's not reflected as part of list-transient and friends.

Third, you can give them a name or version different to the official package. Typically this means adding a custom build suffix and marking the package as frozen. How would you know if you need to rebuild it? Paying attention to the changelog specifically searching for upgrades in those packages and also using the list-versions operation, that lets you view the different known versions of a package, including local and remote ones.

Maintenance

SlackRoll barely requires maintenance. It keeps all downloaded packages in its package cache, located in the /var/slackroll/packages directory. When downloading files, it keeps them in a temporary directory until they're fully downloaded. If you want to remove every downloaded package, you can simply perform slackroll erase-cache. There is, however, a clean-cache operation which does not remove every downloaded package, but only those that are no longer present in the remote tree. Running that operation from time to time keeps your package cache sane and controlled. It may also be a good idea to delete the temporary directory contents from time to time, with slackroll erase-tmp, but it should be empty unless you interrupt SlackRoll while downloading stuff and never attempt to complete the download.

Other Operations

If you run the help operation you will see SlackRoll has many other operations, including operations to list packages by state, list local packages, list remote packages and list all known packages. It has operations to put packages in specific states and checking the state of packages. You can also download, install, display info or remove new or unavailable packages or packages with a matching path (like /slackware/kde/). Finally, there are search operations, to search for packages by name or path, search for files in your local system (like running grep on the contents of /var/log/packages), query the Slackware Package Browser, and finally a few very slow but sometimes useful operations to search for broken symlinks under a specific hierarchy and the same for orphan files (files not belonging to any package), as well as searching for missing files.

As a general rule, every operation either does not accept arguments or allows a list of them. Operations accepting packages as arguments expect the package name only unless the help text mentions that they also accept specific package versions. Some operations need regular expressions. For the most part they have the same syntax as they have in grep or Perl, but you can read the Python regular expressions syntax reference if you want to perform an unusually complex search.

SlackRoll Tutorial

Contents