slackroll

In the following text I’m going to be talking about packages. For package, we are going to understand a named piece of software, without having any specific version unless I explicitly mention it. A package can be bash or kdewebdev or gcc-gfortran, for example.

Each package is in one of several possible states. The program tries to keep a persistent database that associates each package with its state. When it runs, it analyzes the list of packages present in your system, the list of remote packages, and tries to keep the persistent database updated by introducing new entries, deleting old ones and changing the state of some of those entries.

There are several possible states for a package, divided in two groups. First, we have transient states. As a user, your job is to make sure no packages remain in those states for long periods of time. Second, we have the normal states, in which the different packages should normally be.

slackroll works with two types of remote trees. It needs a mirror, which is a URL pointing to a replica of the official Slackware package tree for the Slackware version you’re using. There can be only one mirror and it’s selected with the set-mirror operation, as you will see later.

In addition, slackroll can work with a number of additional third-party repositories. These are managed with the add-repo, list-repos and remove-repo operations, and they will be explained later.

When kernel packages have pending upgrades, you can use two operations created specifically to handle the situation. kernel-upgrade will install the new kernel packages using installpkg instead of upgradepkg and then help you configure your boot loader for the new kernel. This means that, for a small time period, you will have two versions of the kernel packages installed. After a successful reboot to the new kernel, you can use the kernel-clean operation to remove the previous versions of those packages.

As mentioned previously, slackroll can also work with a number of third-party repositories that would normally contain known but unofficial packages for the Slackware version you’re running. If you’re going to work with third-party repositories, I recommend adding them after the initial setup phase described in this tutorial.

You can add a new repository with the add-repo operation. Once you’ve added all the third-party repositories you want, run the update operation to retrieve information about remote packages and the list-transient operation to check the summary of activity.

For slackroll to be able to work with a third-party repository, the repository needs to provide a FILELIST.TXT file in the repository root, and packages need to be signed with external .asc files like the official ones. These package signatures will be verified by the program when downloading packages, which means the signature key needs to be in the superuser’s keyring. It’s very important to note the import-key operation will not download GPG keys from third-party repositories as a security measure. You need to download the keys by yourself and import them with gpg --import KEY_FILE, where KEY_FILE is the path to the GPG key file. Then, you will be able to download and install packages from the repository.

The list of third-party repositories can be printed with the list-repos operation, and you can remove a repository from the list with the remove-repo operation, by providing the repo number as listed with list-repos.

Question: While attempting to setup slackroll I get ERROR: Nonstandard package name: <package>. How can I solve this problem?

Answer: It seems some people are using packages that don’t follow the Slackware package name convention of name-version-arch-build. I think it is wrong to have a package that doesn’t follow the convention. slackroll needs to parse the package names to extract the different components. These packages make it very difficult or impossible, so they are rejected. There is no way to analyze those names properly in a predictable way. The problem should be solved by removing that package, renaming the package archive to have a standard name and then installing it again.

Some examples of invalid package names I have seen reported are pyfloppy-1.6-noarch.2AS, gammapage-0.5.i486-1AS and scons-0.96.1-1.noarch.

Remember: it doesn’t matter if it’s an official package or a foreign or custom one. It should follow the naming convention.

Question: Using the urls or urls-upgrades operation I want to save the URL list to a text file. However, if I use shell redirections and slackroll prompts me to select a specific package version, I can’t see the questions. Is there an easy way of doing this?

Answer: Yes. Pipe the output of slackroll to tee urls.txt and then edit the file to remove the extra lines.

Question: I normally get my packages using rsync, so as to keep a local copy of the remote tree. Can I coordinate this with slackroll?

Answer: Yes. I would use a script like the following one, replacing the chunks in curly braces by the appropriate contents.

This will synchronize your local copy of the remote trees and then populate the slackroll package cache with symbolic links to the package archives located inside your local copy of the Slackware remote trees. From the point of view of slackroll, it’s like if it had already downloaded every package.

Question: Which environment variables affect slackroll?

Answer: TMPDIR lets you specify a temporary directory that will be used to download files before they are moved to their final locations, which is /var/slackroll/tmp by default. PAGER lets you specify a pager program, which is less by default. VISUAL lets you specify a visual editor, which is used to edit single files and is vim by default. SRDIFF lets you specify the diff tool that will be used to edit and compare pairs of files, which is vimdiff by default.

Question: Is it possible to disable syntax highlighting in vim, but only when it’s running in diff mode?

Answer: Yes. Add this to your ~/.vimrc file, taken from the vim help documents:

Question: slackroll sometimes warns me about having multiple versions of the same package installed in my system. Is that a problem? When does the warning appear exactly?

Answer: Having multiple versions of the same package installed may or may not be a problem, depending on the package. For example, when installing a new kernel many people prefer to keep the old one around in case the new one turns out to have critical issues, like inability to boot the computer. This means the system may have several kernel packages installed at the same time. The old kernel packages could be removed after the new kernel is proved to work. See the kernel-upgrade and kernel-clean operations.

However, some other packages may not be prepared to have multiple local versions installed and this may be a problem, so slackroll warns about the situation. The warning can also serve as a reminder to delete old kernel packages after a kernel upgrade. It will be printed any time the program rebuilds the local package list, so you will only see it after having installed, removed or upgraded packages, right after the “Rebuilding local package list” message.

Question: slackroll has a lot of operations available. Some of them are mentioned in the tutorial but, in a few words, which operations do you use more frequently?

Answer: There is a first group of operations everybody will be running very frequently: update, changelog, list-transient and upgrade. If you use a few foreign packages you install and upgrade by hand, you could put install-foreign in that first group too. Some users, specially the ones running slackware-current like I do, would have a second group of common operations they run from time to time: clean-cache, install, remove, remove-unavailable, install-new and not-installed.

Question: What are the differences between slackroll and other tools like slapt-get, swaret or slackpkg?

Answer: That’s a hard question which is better answered by exposing the features of slackroll. In any case, it should be clarified that you can run two types of Slackware installations. On the one hand you have stable releases. If you are going to run a stable release any tool will probably be useful enough for you, including slackroll. This is because stable releases are easy to manage, given that the only events they are exposed to are the release of patches. Any of the existing tools can easily tell you which patches have been released and let you automate the download and installation process. It is extremely rare, but not impossible, for a package to be added to or removed from the tree of a stable release.

On the other hand, you can be running the rolling release of Slackware which serves as the testing tree, called slackware(64)-current, or using third-party repositories. In this case, in my humble opinion, slackroll is the best tool. This is because slackroll lets you track almost any event happening in the remote trees, be it packages being added, removed or upgraded, including the events of a foreign package getting a remote version and the removal of a package for which a customized version was installed. This is possible thanks to its package states foundation and the preference for working with two different states (foreign and frozen) instead of relying on a blacklisting mechanism. No other tool, as far as I know, can deal with as many events as slackroll. I’m unable to imagine an event that is not covered by slackroll.

Apart from the type of Slackware installation you’re running, there’s the issue of using third-party repositories. Starting with version 43 and inspired by community forks of slackpkg, slackroll added support for external repositories, and performs a decent job at handling them. This makes it a viable alternative to slapt-get in those situations. Some of those repositories provide dependency information for packages, which slapt-get can use, while slackroll doesn’t use it.

Compared to the shell-based swaret (there was a new swaret being developed in Perl), slackroll lacks tracking binary dependencies, but it compensates that lack by letting you search for files in remote packages with the manifest-related operations. Apart from that, swaret is incredibly slow and CPU hungry even when it’s only downloading files from the network, and doesn’t come close to tracking as many events as slackroll. slackroll is, in my humble opinion, a clear winner over swaret unless you absolutely love the binary dependency detection and resolution it provides. For me that’s a minor feature. The Perl implementation was supposed to be basically the same, but solving the high CPU usage problem. If that’s the case, slackroll would still be a much better option, in my opinion, because swaret still doesn’t do glibc upgrades properly, does not detect removed packages, etc.

slackroll's closest friend is slackpkg, included in the /extra/ tree. You can think of it like a very much improved slackpkg that works faster, detects more corner cases and has more features. If you run slackpkg, do not hesitate to give slackroll a try. The main difference between slackpkg and slackroll is that the latter, like many other package management tools, keeps a persistent database of packages on disk. For example, slackpkg uses a reliable method of parsing the change log to detect when a package has been added, while slackroll downloads FILELIST.TXT and notices which packages are new because it didn’t have information on them before. This method also works with third-party repositories. Another example is slackpkg's clean-system operation, which prompts you about packages with are not in any official package set. This operation helps you remove packages that have been removed from the official Slackware tree, but you need to blacklist your own packages if you don’t want them to appear in the list. slackroll, on the other hand, can be told those packages are foreign and it remembers that information.

Finally, in general, slackroll is at least as fast or faster than any of the above tools, specially faster than the ones that are big shell scripts (slackpkg and swaret). It downloads less meta-data than any other, because it only needs FILELIST.TXT and, for convenience, the new entries from the change log (indeed, it only downloads the new entries). It detects more events, which is specially useful when running Slackware’s rolling release, slackware(64)-current. And it has some useful features no other tool has, like the operations to detect orphan files, broken symlinks and missing files. You won’t have to run grep on the contents of /var/log/packages anymore, because it has a local search operation. It lets you download and search the MANIFEST list for specific files if, for example, you’re missing a library. It also lets you choose which package version to install when there are several ones available. It lets you upgrade individual packages or every upgrade-able package, install new packages, remove old ones, search for package names or packages with a given tree component, list alternative versions of packages, detect and warn you about activity in glibc packages (giving them priority while upgrading too), etc.