Announcing lorax-0.1

"I am the Lorax, I speak for the trees."

(and images)


WHAT IS IT
----------

lorax is a replacement for the buildinstall maze of scripts and tools we
have in anaconda.  It is written in Python in the hopes that it will be
easier to hook in to programs like pungi.

It also moves the tools that generate installation images in to a separate
project from anaconda itself.


WHAT DOES IT REPLACE?
---------------------

All of these things from the anaconda source tree:

     scripts/buildinstall
     scripts/buildinstall.functions
     scripts/makestamp.py
     scripts/maketreeinfo.py
     scripts/mk-images
     scripts/mk-images.alpha
     scripts/mk-images.efi
     scripts/mk-images.ia64
     scripts/mk-images.ppc
     scripts/mk-images.s390
     scripts/mk-images.x86
     scripts/scrubtree
     scripts/upd-instroot

     utils/trimpciids
     utils/mk-s390-cdboot.c
     utils/filtermoddeps
     utils/geninitrdsz.c
     utils/genmodinfo
     utils/modlist


WHY REWRITE BUILDINSTALL
------------------------

The buildinstall scripts were magic and maintaining them was sort of an art
form.  The entire collection of tools used in a buildinstall run are written
in bash, Perl, Python, and C.  Maintenance nightmare.

The way packages were specified for inclusion in the instroot as well as
what files were to be kept or removed were specified in the upd-instroot
script.  Again, difficult maintenance.

Lorax is intended to mostly be a drop-in replacement for buildinstall.  The
frontend program accepts the same command line arguments as buildinstall,
but all of the work is done through the pylorax Python module rather than
separate scripts or programs.


MAJOR CHANGES
-------------

Aside from offering a standalone tool that replaces the buildinstall script
collection and being written in Python, lorax introduces some policy changes
for how install images are generated.

(a) Keep everything by default, remove listed items.

In the buildinstall scripts, we have the KEEPFILE set of variables that
define what files (by wildcard or explicit names) we want to keep in a
particular image.  The standard policy for buildinstall is to unpack a set
of packages (listed in PACKAGES variables) and then remove everything not
explicitly listed in a KEEPFILE variable.  This aspect causes a lot of
maintenance headaches.

The lorax approach is to trust yum and package maintainers to give us what
we want.  We define a set of packages we want for the image using
configuration files in /etc/lorax.  Using yum, the packages are installed to
the staging root tree.  Then tree scrubbing takes place, which is
customizable by the user.  So, the default policy of lorax is to keep
everything a package gives us and only remove things explicitly listed for
the scrub operation.

(b) Maintain image building tools as a separate project.

If release engineering needs to regenerate trees for a nightly build because
a problem was encountered during image building, that requires a new
anaconda build to show up.  Lorax allows customization through configuration
files and in cases where bugs are discovered in it, a new release can be
made independent of anaconda.

Lorax can (and should) be maintained jointly by releng and the anaconda team.

(c) Logic is in the pylorax module.

Pungi may ultimately import the pylorax module to generate images rather
than running the lorax command line tool.  Better integration in to Pungi
is a goal of lorax.


And there you have it.  Lorax.

-- 
David Cantrell <dcantrell@redhat.com>