Lorax is a set of tools used to create bootable images.
Go to file
Martin Gracik 73b62e0cf5 Add yum-langpacks yum plugin to anaconda environment (notting)
This allows for installation of package's language packs without needing to
list them explicitly in the <foo>-support comps groups. Those groups (and
the corresponding code in yuminstall.py) are still needed at least in the
short term, due to fonts, input methods, and some internal architecture
issues in the plugin.
2011-03-15 16:39:45 +01:00
etc Remove empty config files 2010-12-08 12:40:46 +01:00
pseudo Minor sparc pseudo code changes 2011-03-14 13:58:38 +01:00
share Add yum-langpacks yum plugin to anaconda environment (notting) 2011-03-15 16:39:45 +01:00
src Replace variables in yaboot.conf 2011-03-15 16:38:08 +01:00
utils Don't append yum output to the diff file 2010-12-03 09:53:21 +01:00
.gitignore Ignore *.pyc files. 2008-09-12 12:10:33 -10:00
0001-Lorax-patch.patch Pungi patch for using lorax 2010-11-08 15:41:01 +01:00
ANNOUNCE Added draft on initial announce email as I keep adding to it. 2008-10-06 09:51:01 -10:00
AUTHORS New version 2010-02-23 14:20:05 +01:00
COPYING Initial project description files imported. 2008-09-11 14:16:39 -10:00
lorax.spec New version 2011-03-14 12:34:25 +01:00
Makefile Makefile updates 2010-12-08 14:16:13 +01:00
POLICY Update the POLICY file. 2008-10-03 15:45:33 -10:00
README Initial project description files imported. 2008-09-11 14:16:39 -10:00
setup.py Setup and spec file changes 2010-12-17 17:04:04 +01:00
TODO Update TODO list. 2009-04-06 09:54:22 -10:00

I am the Lorax.  I speak for the trees [and images].

Tree building tools such as pungi and revisor rely on 'buildinstall' in
anaconda/scripts/ to produce the boot images and other such control files
in the final tree.  The existing buildinstall scripts written in a mix of
bash and Python are unmaintainable.  Lorax is an attempt to replace them
with something more flexible.


EXISTING WORKFLOW:

pungi and other tools call scripts/buildinstall, which in turn call other
scripts to do the image building and data generation.  Here's how it
currently looks:

   -> buildinstall
       * process command line options
       * write temporary yum.conf to point to correct repo
       * find anaconda release RPM
       * unpack RPM, pull in those versions of upd-instroot, mk-images,
         maketreeinfo.py, makestamp.py, and buildinstall

       -> call upd-instroot

       -> call maketreeinfo.py

       -> call mk-images (which figures out which mk-images.ARCH to call)

       -> call makestamp.py

       * clean up


PROBLEMS:

The existing workflow presents some problems with maintaining the scripts.
First, almost all knowledge of what goes in to the stage 1 and stage 2
images lives in upd-instroot.  The mk-images* scripts copy things from the
root created by upd-instroot in order to build the stage 1 image, though
it's not completely clear from reading the scripts.


NEW IDEAS:

Create a new central driver with all information living in Python modules.
Configuration files will provide the knowledge previously contained in the
upd-instroot and mk-images* scripts.


-- 
David Cantrell <dcantrell@redhat.com>