Geek Blight

Yesterday I published version 1 of SlackRoll, a package or update manager for Slackware Linux. For those who don’t know Slackware very well, Slackware is maintained mainly by a single individual, a man called Patrick Volkerding. It outstands for being a very simple distribution (internally, not simple to use), quite stable and having a very simple package manager (called pkgtools) that doesn’t track any sort of dependencies and doesn’t know about remote repositories. The user needs to download packages by hand as patches or new versions are published, and use the pkgtools to install or upgrade those packages. This simple system is robust in the sense that it’s very hard to break and is unlikely to fail and leave your system in an unusable state. However, the lack of a way to automatically download updates and new packages (among other things) has prompted the appearance of some tools to do this job, which sit on top of the classic pkgtools. The most famous ones are swaret, slapt-get and slackpkg, this last one being distributed as part of the official Slackware, inside the extra directory. I have used those three at different points in time.

Slackware is a very flexible distribution and leaves room for the user to decide how to manage their system. Some users think the limited number of official packages and the lack of dependency checking is a problem, and like to download packages from the user-driven site linuxpackages.net, which sometimes provide dependency information that slapt-get can use. Some other users think the official package selection is quite complete and compile themselves the few packages they need and are not present in the official tree. Sites like slackbuilds.org let you download many so-called SlackBuilds, shell scripts that extract, compile and create a Slackware package from official package sources if you don’t know how to create them yourself. For this second group of users, the semi-official slackpkg is a good option, letting you download packages automatically, detecting new packages, packages that have been removed and updates. It also has a mechanism to blacklist packages so they are not upgraded normally. That’s very useful to avoid disasters upgrading important packages and to let you have custom versions of official packages.

I consider myself to be in that second group. My system mainly has official packages and a handful of unofficial ones I compile myself. However, while I think slackpkg is a very good tool, I was not fully satisfied by it. In particular, I thought it was a bit slow (it’s a big shell script), I didn’t like its interface (it uses dialog for some operations, lets you see the output of wget when it downloads…​ in other words, it’s not very uniform) and I also didn’t really like the blacklisting mechanism because removing items from the blacklist had to be done by hand. In my state of partial dissatisfaction I started thinking about creating my own package manager, in the line of slackpkg but fixing its "problems". One day I had so many ideas in my head that I decided to get them out and put them on paper. I grabbed a pen an decided how everything could be done. I decided which package states I needed, I came to the conclussion that I needed three package lists (local, remote and persistent) and immediately saw the main problem was creating the algorithm to update the persistent list/database. I tought about it and put the algorithm on paper. It hasn’t been modified since then. The main work involved two afternoons and evenings, but since then I’ve fixed some bugs, added some commands and changed small aspects of it from time to time, but without adding significant development time. It can still be considered a two-day job.

The end result is a Python script that reflects my view on Slackware package management, with a uniform interface, which works fast enough for me (local operations take less than one second in my system) and which lets you download and install packages and updates automatically and is, I think, quite good at showing you which packages have been added or removed from the official tree. Unlike slapt-get and sometimes swaret, it’s able to detect reverts to previous versions properly. This happens from time to time in the rolling tree when a new version introduces too many problems.

Its name stems from the fact that I initially designed the program to work with the rolling Slackware tree (slackware-current) but after it was finished I thought it could be easily adapted to work with the stable tree doing some trivial changes. I kept the name, however. I also want to thank Patrick Volkerding for maintaining Slackware and for kindly answering a batch of questions I sent him. Remember, if your Slackware system has mainly official packages and a few unofficial ones, please give slackroll a try. You may like the way it works. For me, more users mean more eyes to spot bugs and suggestions to drive slackroll to perfection. All the relevant information and instructions can be found in its webpage.

Happy Slackin'!