From 7e62446b3e2a44197bf6bc84676e3e98c93f8357 Mon Sep 17 00:00:00 2001 From: David Cantrell Date: Mon, 6 Oct 2008 09:51:01 -1000 Subject: [PATCH] Added draft on initial announce email as I keep adding to it. --- ANNOUNCE | 107 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 107 insertions(+) create mode 100644 ANNOUNCE diff --git a/ANNOUNCE b/ANNOUNCE new file mode 100644 index 00000000..53631db1 --- /dev/null +++ b/ANNOUNCE @@ -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