Lorax is a set of tools used to create bootable images.
Go to file
Brian C. Lane bebec0cf58 lorax: Update how the release package is chosen
Previously the release package was chosen by picking the first package
that provides 'system-release' that isn't named generic. This can cause
branding issues with repos containing multiple system-release packages.

This patch changes _install_branding so that it will give preference to
a system-release package that ends with lowercase --variant name. If
there isn't one it will fall back to the previous behavior.

Resolves: rhbz#1472622
2020-03-03 17:18:34 -08:00
docs Add documentation for --dracut-arg to lorax.1 2018-08-15 09:03:32 -07:00
etc Add support for yum to lorax-composer 2018-06-11 16:54:58 -07:00
rel-eng Automatic commit of package [lorax] release [19.7.26-1]. 2019-12-16 09:34:59 -08:00
share Remove unneeded scap-security-guide files 2019-12-13 10:46:59 -08:00
src lorax: Update how the release package is chosen 2020-03-03 17:18:34 -08:00
systemd lorax: Move default tmp dir to /var/tmp/lorax 2019-01-22 17:12:56 -08:00
tests Remove lorax-composer tests 2019-02-27 09:10:39 -08:00
utils Don't redefine variables from outer scope 2018-06-11 16:54:57 -07:00
.coveragerc Measure coverage for parallel processes 2018-06-11 16:54:58 -07:00
.dockerignore Update how we pass the source to docker so it includes docs/ dir 2018-06-11 16:54:58 -07:00
.gitignore Add composer-cli utility and implement the recipes commands 2018-06-11 16:54:58 -07:00
.travis.yml Properly report coverage 2018-06-11 16:54:58 -07:00
ANNOUNCE Added draft on initial announce email as I keep adding to it. 2008-10-06 09:51:01 -10:00
AUTHORS add wwoods to AUTHORS 2011-10-26 12:36:06 -04:00
COPYING Initial project description files imported. 2008-09-11 14:16:39 -10:00
Dockerfile.test Execute bash tests for composer-cli 2018-10-01 12:35:23 +02:00
epel.repo Enable testing in Travis CI using Docker container 2018-06-11 16:54:58 -07:00
lorax.spec Automatic commit of package [lorax] release [19.7.26-1]. 2019-12-16 09:34:59 -08:00
Makefile Remove lorax-composer tests 2019-02-27 09:10:39 -08:00
POLICY Update TODO and POLICY to reflect the current state of things 2012-01-06 14:41:21 -05:00
README Initial project description files imported. 2008-09-11 14:16:39 -10:00
README.livemedia-creator Document kickstart restrictions on %include (#1418500) 2017-08-11 15:11:30 -07:00
README.product Update docs for product.img (#1272361) 2016-02-19 16:41:58 -08:00
setup.py lorax: Move default tmp dir to /var/tmp/lorax 2019-01-22 17:12:56 -08:00
TODO Update TODO and POLICY to reflect the current state of things 2012-01-06 14:41:21 -05: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>