Lorax is a set of tools used to create bootable images.
bbd1592f43
iscsi-initator-utils and gobject-introspection actually are required via anaconda rpm deps, so they aren't needed in runtime-install.tmpl. Nothing seems to actually use python-imaging (i.e., python-pillow). The executables for polkit, gnome-keyring and python-ethtool are removed in runtime-cleanup, so if anything needs the libraries in these packages, they can be pulled in through rpm dependencies. Among them, only polkit is required. For LUKS escrow stuff, keep the packages that provide the command-line executables (volume_key, nss-tools), and remove the libraries. The python2 libraries are no longer needed by blivet, and libblockdev will install the C libraries it needs. Install the dnf langpacks plugin instead of the yum one. python-epdb is less useful now that anaconda is Python 3. |
||
|---|---|---|
| docs | ||
| etc | ||
| rel-eng | ||
| share | ||
| src | ||
| tests | ||
| utils | ||
| .gitignore | ||
| ANNOUNCE | ||
| AUTHORS | ||
| COPYING | ||
| 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>