Lorax is a set of tools used to create bootable images.
bb652368dc
Templates are under the share dir, so use find_templates() to find them. |
||
---|---|---|
docs | ||
etc | ||
rel-eng | ||
share | ||
src | ||
systemd | ||
tests | ||
utils | ||
.coveragerc | ||
.dockerignore | ||
.gitignore | ||
.travis.yml | ||
ANNOUNCE | ||
AUTHORS | ||
COPYING | ||
Dockerfile.test | ||
lorax.spec | ||
Makefile | ||
POLICY | ||
README | ||
requirements.txt | ||
setup.py | ||
TODO |
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>