Added draft on initial announce email as I keep adding to it.
This commit is contained in:
parent
77684f0271
commit
7e62446b3e
107
ANNOUNCE
Normal file
107
ANNOUNCE
Normal file
@ -0,0 +1,107 @@
|
||||
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>
|
Loading…
Reference in New Issue
Block a user