swpkg - Software Packaging

So, you have adopted the swpkg philosophy and followed the Docs for some time now. Before long, you have installed more software than you thought you would, and you are now looking at an aging software base. This is a stage where things may become a little overwhelming, especially as you will start upgrading existing software packages, and in particular, packages on which several other packages depend. Thankfully, it's all much easier to manage than if you hadn't used the swpkg philosophy which is far from being limited to the build and installation aspects of third party software packages.

Version 0.9 and 0.10 of the swpkg tools brings several improvements (including several new tools) that will significantly help in these tasks. This document describes what tasks you should perform, and how to go about them.

There is really not that many things that need to be done on a regular basis to keep installed software from rotting in place. Some apply no matter how the software has been installed. However, others are the direct result of the swpkg philosophy, and while these can be overlooked, it is not recommended. Here is really what we are looking at:

• Maintaining man page indexes
• Maintaining info document directories
• Scanning directories for stray and stale links
• Dealing with package upgrades and removal

UNIX systems all come with manual pages installed, and their indexes. Because of the widespread use of man pages, both by vendors and for third party packages, vendors typically include a tool to maintain the indexes on their systems. The upside of this is that maintaining indexes for third party packages installed with the swpkg tools is a simple matter of using this provided tool. The downside is that there is really no standard way of doing it as each vendor has its own often slightly different approach. The most common tool used for this is catman, so check your vendor documentation and setup a cronjob to take care of the work for you.

Unlike manual pages, info documents are mostly (if not only) used by third party (usually free) software packages. Because of this, not only most vendors don't provide anything to deal with these, but most packages providing such documents expect to have to update the directory at install time. With swpkg each package is installed separately, and so one quickly ends up with a multitude of directory files all useless because the info tools (such as GNU TeXinfo and GNU Emacs) only expect a few directory files.

This is why the default .swrc file suggests to link info documents in the target directory. Then, all that needs to be done is to maintain the directory file. This may be done either after every invocation of swln or simply on a regular basis by using swinfo (included in the swpkg tools).

In an ideal world, this would not be necessary. However, the following (among others) may cause links to fall out of date with the supposed state of the system:

• Changes to global .swrc file(s)
• Changes to existing packages (such as the addition of Perl modules)
• Careless deletion of a package

When upgrading (or removing) a software package, there is really only one thing to be careful with: Not leaving links behind. This is easy to deal with using swln's -i which reports on installed packages as well as inter-package dependencies.

Upgrading a package which other packages depend on is a simple matter of installing the new version, and updating the links for all of these packages, one by one. Of course, it is recommended to test these packages after the dependency upgrades.

© 2001-2008 - Christophe Kalt