SlackRoll is ready
It’s been a couple of months since I initially published the first version of SlackRoll, my particular upgrade manager for Slackware. I have announced it in a couple of main sites like Slashdot and the LinuxQuestions.org Slackware forums. The program hasn’t really taken off in the number of users, but I’m glad about the result in any case. It’s about to be tagged stable in both SourceForge.net and freshmeat.net. I didn’t have many chances of using it at its full potential, but I’m sure Patrick Volkerding will start making serious changes to the rolling tree soon now that Slackware 12.0 is out, and people will have a real oportunity of realizing how much time SlackRoll can save you.
Like I said in my previous post about SlackRoll, I started the project because I didn’t like the other available upgrade managers and wanted a faster and more bandwidth friendly upgrade manager, one that could save me more time, and I really did what I wanted. SlackRoll lets me read the ChangeLog without paying attention to the minor entries, the ones that announce that a package has been added or removed or upgraded, and focus on entries with more detailed comments. It knows about almost every corner case and notifies you of any important event, be it glibc upgrades, normal upgrades, new packages, removed packages, custom packages that get an official version or customized packages that are removed.
There have been many changes since version 1 to the now available version 14. Two important changes stand above others. The first one, a security fix in the GnuPG exit status treatment. I don’t know what I was thinking when I coded the initial version, but I screwed up and introduced a nasty bug that was fixed around version 8, if I recall correctly. I also changed the number and meaning of some package states. My initial design, that one I was so proud of, didn’t last long when I realized I could save time and detect more corner cases by introducing some changes. First off, the "outdated" state was initially calculated on the fly, when the user requested the upgrade or list-upgrades operations, for example. I realized I could save a lot of computing time by making outdated a state on its own and calculate it once. Second, the custom state was replaced by two different states in order to detect a couple more corner cases, which are the foreign state and the frozen state. Apart from that, there have been many feature enhancements, speed improvements and general code cleanups. For example, now the program caches the list of local packages and remote packages, supports having more than one local version of a package, implements several interesting search functions, orphan file detection and broken symlinks detection, among other changes. They are too many to be listed here, but SlackRoll is now my swiss army knife of Slackware package management, and it works faster and better than ever.
I would also like to encourage people to do things The Right Way. Remember to read the ChangeLog, subscribe to the slackware-security mailing list and give preference to SlackBuild scripts over third party packages, and avoid LinuxPackages.net if possible. Sites like SlackBuilds.org are a good resource if you want to introduce foreign packages in your system (using SlackRoll terminology ;).
Are you a Slackware user and haven’t tried SlackRoll? Don’t hurry to try it. SlackRoll is here to stay. :D