swpkg - Software Packaging

To any seasoned system administrator, building and installing third party packages is, at least for most packages, a simple task. And indeed, things have dramatically improved from the earlier days of UNIX where Chaos seemed to reign, and portability doomed. A number of tools have emerged to make the lives of developers, but also of adminitrators easier.

What is unfortunate is that these tools really only address part of the problem about distributing a software in source form for it to be built on various OS types, versions, and in random environments. They do not provide fool proof methods for building software, and won't keep you from shooting yourself in the foot.

The following principles should be viewed as a set of strong recommendations to be followed by people in charge of building third party software. These are relatively generic rather than specific to the "swpkg philosophy", and simply try to promote sane habits and methods for building software.

1. Don't build software as "root".
2. Don't install software as "root". (This is of course not always possible for a variety of reasons ranging from poor packaging to real necessity.)
3. Ideally, installing software should be done with an account that has the minimum necessary permissions to be able to carry such operation. In particular, it shouldn't have permission to modify other already installed software.
4. Use a sanitized environment to build software. In particular, remove any unnecessary variable, and define the PATH variable properly: Noone wants to end up with a piece of software depending on binary found under your home directory!
5. Keep details about the build: environment, compiler version, anything that would be useful to rebuild the software several years from now. (It's quite difficult to know how much to keep.)
6. Keep the source you used: it may be needed several years later to rebuild the software. Some simply keep tarballs, others use CVS and import all versions in their repository. The latter is definitely worth the trouble if you have made modifications to the code, but probably overkill of not.
7. Use some type of source control system on locally developed software/scripts: Lost? Check out Subversion.

© 2001-2008 - Christophe Kalt