Check out the new USENIX Web site. next up previous
Next: Distribution Specific Paths Up: The Solution Previous: The Solution


Implementing the Solution

The most appealing implementation would be to use the virtual package feature of rpm, so we have a single package for each distribution containing the distribution dependent components for that distribution. These distribution packages would all provide the same virtual package, which the distribution independent packages would require (see Figure 1). Unfortunately, rpm is not quite flexible enough to be used in exactly this way.

The basic issues are:

In the end, we decided to create a setup script for each distribution to handle the initial setup tasks:

  1. Recognise the distribution or exit 1 (all other error exits start from 2 up).
  2. Analyse the configuration and compute the upgrades required.
  3. Inform the user what needs to be done and request permission to proceed.
  4. Only if the user permits us to install the required upgrades, install the distribution dependent component providing the virtual package.

Using step 1, we can now place a collection of these on a CD in individual directories and have a top level setup script which invokes each of the subdirectory setups in turn until it finds one that doesn't exit 1. Adding support for a new Linux distribution consists of simply adding an additional subdirectory, including the necessary setup script and distribution rpm package, to the CD.

One of the final benefits to this approach is that we can also bundle software that isn't distributed with the target OS on the CD. This came in very handy for us since our GUI is written in Java, but in 2000 only Caldera had a bundled JVM.

Finally, it is necessary to adhere to a set of rules that ensure general portability of the core components. The essentials of these are:

  1. Never use absolute paths in scripts. Always use commands by their non-path qualified name so that the PATH variable may be updated per distribution to find the correct command.
  2. In compiled programs, always use POSIX APIs found in the standard glibc if possible rather than non-standard APIs which are found in libraries not present on all distributions.
  3. Never ``hardcode'' fixed parameters. Always load them from some type of defaults file so they may be modified in the field (or by a distribution enabling script) if necessary.
  4. Resist the ``latest greatest'' craze. Beware of trying to code an application for the latest whiz bang feature since most distributions will pick this up more tardily than you anticipate. Unless absolutely essential (and you can work out how to deliver the functionality yourself) always code to APIs which exist on distributions today.


next up previous
Next: Distribution Specific Paths Up: The Solution Previous: The Solution
James Bottomley 2001-09-13