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:
- Inability to modify one package from within the installation of
another (prevents the installation of required upgrades and patches).
- No interaction allowed (it is unacceptable for us just to modify
the installed operating system without explaining to a user what we
want to do and asking permission to proceed).
In the end, we decided to create a setup script for each
distribution to handle the initial setup tasks:
- Recognise the distribution or exit 1 (all other error exits
start from 2 up).
- Analyse the configuration and compute the upgrades required.
- Inform the user what needs to be done and request permission to
proceed.
- 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:
- 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.
- 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.
- 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.
- 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: Distribution Specific Paths
Up: The Solution
Previous: The Solution
James Bottomley
2001-09-13