SlackRoll: Manage a Slackware system

slackroll is a package or update manager for Slackware systems. It does not provide dependency checking and uses pkgtools to install or upgrade packages. It's designed to work with official mirrors. If you have a Slackware system mainly composed of official packages and a handful of unofficial packages, slackroll can help you manage it and keep in touch with the remote tree. It tries to know when new packages appear, when packages are removed and when packages are upgraded.

So you have decided to try slackroll. Let me introduce a few concepts so you don't get lost.

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.

A package is in this state when it's present in the remote tree and it wasn't present before. If you detect you have packages in this state you should decide if you want to install them or mark them as not installed. This state lets you see which packages are being added to the remote tree.

Sorry if this name is somehow confusing. A package is in this state when it's present in your system, but not in the remote tree. You should decide if you want to remove them from your system or mark them as foreign packages. This state lets you see which packages are being removed from the remote tree.

A package is outdated if it's present in your system and in the remote tree, but the local version does not match any relevant one in the remote tree. The program will try to upgrade these packages.

A package is installed if it's present in your system and in the remote tree, and the local version is not outdated. Very common state, as you can suppose.

A package is not installed if it's a known package which is not present in your system but exists in the remote tree. It's also a very common state.

No package will enter the frozen state unless you mark it so. It should be used for packages present in your system and in the remote tree, but that you don't want to upgrade automatically. This state can be used for packages which are not meant to be upgraded automatically or ever, like aaa_elflibs and others, and probably for customized versions of official packages. For example, my custom build of freetype is marked as frozen. You must pay attention to these packages, as upgrades to them will be silently ignored. You may find the list-versions and list-outdated-frozen operations useful to detect version mismatches between your local copy and the ones in the remote tree. Having a package in the frozen state does not prevent you from using the install operation to download and install a different version. If the package ever disappears from the remote tree, it will be marked as unavailable and you will probably see it. You could continue to use it by marking it as foreign if you wish.

No package will enter the foreign state unless you mark it so. It should be used for packages that do not exist in the remote tree but that, unlike unavailable packages, are present in your system on purpose. For example, the slackroll package in my system is marked as foreign. A foreign package will be marked as installed or outdated if it ever appears in the remote tree, becoming a candidate for upgrading. Hopefully, you'll notice this fact. You could still use your own version instead of the remote (official) one by marking it as frozen.

slackroll is a self-contained Python script released to the public domain. You can install its package with installpkg for the first time. In the future, you can use upgradepkg or even slackroll itself to upgrade to newer versions. Continue reading for more details.

slackroll requires python, pkgtools, gnupg (or gnupg2), an editor and diff tool (which are vim and vimdiff by default (provided by package vim), and a pager (less by default) to operate properly.

It should be noted that you can start using slackroll whenever you want, but my advice is to do it when your system is under control and there are no upgrades pending. This will give you a chance of configuring the program and setting the package states properly without making serious mistakes.

You should first choose a Slackware mirror. Take into account slackroll will store downloaded packages in a subdirectory of /var/slackroll, so you will probably need to have a good amount of space available for them in there. Set the mirror URL with the set-mirror operation. For example:

Do not forget the trailing slash! Great. You are ready to start. Retrieve the remote GPG key to add it to your keyring. Having the GPG key is required, and it should be safe to do this step even if the key is already in your keyring. You can also get the key from the Slackware CD or DVD. The GPG key and the package signatures will be downloaded from a primary mirror instead of the mirror you chose, in order to increase security.

Retrieve information about the remote packages. You'll have to perform this step every time Patrick Volkerding changes the remote tree.

Finally, you could start checking if there are new packages, unavailable packages or upgrades. However, the first time you use slackroll, any package not installed in your system will be marked as new, every foreign package will be marked as unavailable, and every customized package will probably be a candidate for upgrading if you try to do so. If you have your system under control (and I hope you do!), you can in most cases blindly mark all new packages as not installed. There's a command to do it, being a common first operation.

In most cases, you can also mark any unavailable packages as foreign. However, the number of foreign packages is usually quite low, and forgetting to uninstall a package which has been removed is a very common mistake, so my advice is to review the list of unavailable packages by hand, detecting which ones may not be foreign packages and need to be uninstalled.

Once you've got rid of old packages (using removepkg or the remove operation), mark the rest as foreign packages.

Some people like to "blacklist" packages so they are not upgraded normally. Almost always, you want to do this with the package aaa_elflibs if it's present in your system, and maybe with some other packages. If you don't want them to be upgraded normally, they belong to the frozen state. Mark them as frozen. The same applies to customized builds of official packages.

The frozen operation accepts a list of packages as its arguments. You don't need to issue a separate command for each one of them.

Regarding customized versions of official packages, there are at least three ways of dealing with them. Some people prefer to give them version names that match the official ones, despite being customized builds, and keep them in the installed state. The program will want to upgrade them automatically in that case, and maybe the official version will overwrite the custom one after an upgrade, before you rebuild it, if you don't mark it as frozen in the mean time. Some other people prefer to do the same but putting the package permanently in the frozen state. In that case, list-outdated-frozen is useful to detect version mismatches between your local copy and the remote ones. Finally, some other people prefer to give them custom version names, normally via personalized build numbers that usually include some packager initials, and mark them as frozen. In that case, list-versions can help you see if your local copy needs to be rebuilt for a new version.

You can run slackroll help to get a full list of operations and a brief description of each one. A full description of each operation can be found in the operations guide. This program is not a perfect tool. I think it can handle almost every situation and be told to do exactly what you want, but reading the change log and subscribing to the slackware-security mailing list is highly recommended.

In every case you should update whenever the remote tree is changed. Then, you should read the changelog with the changelog operation if there are new entries and, finally, the list-transient operation will provide a summary of activity. There should be no transient packages after you're finished.

Watch out for upgrades in the glibc-solibs, sed and pkgtools packages. They should always be the first ones to be installed or upgraded in that order, even before new packages. You can use the upgrade-key-packages operation to upgrade them first.

When installing or upgrading foreign packages, you can use installpkg or upgradepkg and then mark them as foreign if needed. However, you can also install them using the install-foreign operation to save time and avoid problems.

Also, remember to run the clean-cache operation from time to time to get rid of old and outdated package archives stored in the package cache.

Apart from the list-transient operation, you can check for new packages with list-new. Decide to download and install them with install or mark them as not installed with not-installed. List possible upgrades with list-upgrades and upgrade to new versions with upgrade. Finally, list unavailable packages with list-unavailable and remove them or mark them as foreign if a new foreign package is present in the list. This may happen if you had forgotten to mark it when you installed it (and this is the reason why the install-foreign operation exists).

Mostly the same, but in the stable tree it's extremely rare to see packages being removed or being added to the tree, so you probably won't need to run list-new or list-unavailable, but you never know. The list-transient operation may be useful to detect these rare cases.

I'm all open for good bug reports and general feedback but I'm, as always, reluctant to change the main program concepts, like adding support for multiple mirrors, or adding dependency support or probably adding more package states. I also know the program currently can't be used to upgrade the system in non-interactive mode (like calling it from a cron entry). That is very unlikely to change, because when there's an upgrade, there's no easy way to decide which version should be installed if a package has a version in the main tree, another one in /extra/ and another one in /testing/, so it's always going to need user input.

If you have a question, you should first read the FAQ. For other questions, comments or suggestions, my contact information can be found at freshmeat.net. Keep in mind I'm using the program under slackware-current. If you detect a problem under the stable version, please report it as soon as possible because it may go unnoticed to me.