Next: updaterpms
Up: Linux-Specific Issues
Previous: Installation Bootstrapping
The original version of LCFG used a program called lfu
[2] to update software on the local disks. At that time,
clients tended to have smaller disks and mount much of their software
from the network, so lfu was mainly concerned with synchronising
a comparatively small number of replicated servers, and the
performance would be poor for a large number of clients. There was
also no obvious candidate for a package format which was widely
supported by the packages that we wanted to install; lfu
provides a crude mechanism for matching files to their packages, based
on file ownership, but this was not always adequate. More importantly,
it was also difficult to keep track of the link between binaries and
their corresponding sources.
In theory, lfu could have been used under Linux, but the Redhat
distribution is based on the RPM package management software which
provides a much better mechanism for managing software packages. Many
of the packages that we require are also distributed in this format.
Although there are now numerous programs available for updating and
distributing RPMS (for example [13,11,5,10]),
few of these tools were available in 1997. We also wanted to interface
with the LCFG and provide automatic installation, upgrade and deletion
of RPMs. The Linux version of LCFG therefore uses a
locally-developed program called updaterpms. This is currently
written in C and makes use of rpmlib
2(rewriting this in Python is a possibility now that there an rpmlib interface available).
Footnotes
- ...rpmlib
2
- The latest version of updaterpms needs a modified
version of rpmlib to support per-package options
Subsections
Next: updaterpms
Up: Linux-Specific Issues
Previous: Installation Bootstrapping
Paul Anderson & Alastair Scobie