2008-09-13 01:05:30 +00:00
|
|
|
Policies for initrd.img and install.img image generation.
|
|
|
|
|
|
|
|
|
|
lorax takes a different approach than the previous buildinstall set of scripts
|
|
|
|
|
for generating the boot and install images and tree data files. First, the
|
|
|
|
|
main ideas:
|
|
|
|
|
|
|
|
|
|
* Configuration files control the list of packages to make images with.
|
|
|
|
|
|
|
|
|
|
* Rather than explicitly listing the files to keep in the images (i.e.,
|
|
|
|
|
we used to have KEEPFILE variables in upd-instroot), we now take what
|
|
|
|
|
the packages lay down and do a minimal tree scrubbing (remove docs,
|
|
|
|
|
for example). This is customizable through configuration files
|
2008-10-04 01:45:33 +00:00
|
|
|
because we will always have exceptions. But the policy in lorax is
|
|
|
|
|
opposite of the buildinstall policy: take everything that RPMS lay
|
|
|
|
|
down, remove what we don't want--rather than removing everything
|
|
|
|
|
that is not explicitly listed in KEEPFILE variables.
|
2008-09-13 01:05:30 +00:00
|
|
|
|
|
|
|
|
* The main root tree generated from the package set is broken in to
|
|
|
|
|
/usr for the install.img and everything else for the initrd.img.
|
|
|
|
|
This is configurable through configuration files since we will
|
|
|
|
|
always have exceptions.
|
|
|
|
|
|
|
|
|
|
* Static data such as files we need to place in /etc in the images or
|
|
|
|
|
other control files are stored in /usr/share/lorax and copied in to
|
|
|
|
|
the image staging tree.
|
|
|
|
|
|
|
|
|
|
The approach of taking what the packages give us is a decision to make
|
|
|
|
|
maintenance of the image building tools easier. Whatever the packages lay
|
|
|
|
|
down should be sufficient for the installation images and we shouldn't
|
|
|
|
|
have to have our own list of files to keep and library gathering routines.
|
|
|
|
|
Let the packaging tools figure that out.
|
|
|
|
|
|
|
|
|
|
The whole tool is written in Python with a driver program ("lorax"), but the
|
|
|
|
|
actual logic for the program is in the pylorax module. The idea behind this
|
|
|
|
|
is that tools such as pungi can potentially import pylorax directly and not
|
|
|
|
|
have to run the command line tool to do image generation work. That is,
|
|
|
|
|
pungi can use lorax programatically.
|
|
|
|
|
|
|
|
|
|
This tool is still in the early stages of development (Sep 2008) and patches
|
|
|
|
|
and comments are welcome.
|
