almalinux
/
lorax
14
0
Fork 0
Code Issues Pull Requests Releases Activity

Update TODO and POLICY to reflect the current state of things

This commit is contained in:
Will Woods 2012-01-06 14:41:21 -05:00
parent 5e411b09c0
commit 80066b1e73
2 changed files with 32 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

55
POLICY
View File

@ -1,40 +1,27 @@
Policies for initrd.img and install.img image generation. Lorax is a tool for building bootable/installable Fedora images. Its primary
focus is Fedora installation images but it should be able to create other
types of images too.
lorax takes a different approach than the previous buildinstall set of scripts Some design precepts:
for generating the boot and install images and tree data files. First, the
main ideas:
* Configuration files control the list of packages to make images with. * It should be easy to make small changes to images.
- Image configs should be extendable/inheritable
- Configs should be self-contained and portable - everything in one dir
- kickstart, templates, config files, image-specific data files
(bootloader templates, keymaps, service files, etc).
* Rather than explicitly listing the files to keep in the images (i.e., * Templates should be brief but expressive.
we used to have KEEPFILE variables in upd-instroot), we now take what - Don't make the user maintain huge lists of files/packages
the packages lay down and do a minimal tree scrubbing (remove docs, (do filename globbing and brace expansion, resolve package deps, etc.)
for example). This is customizable through configuration files - Provide commands that allow blacklists/exceptions
because we will always have exceptions. But the policy in lorax is (e.g.: removefrom PKG --allbut FILE FILE...)
opposite of the buildinstall policy: take everything that RPMS lay
down, remove what we don't want--rather than removing everything
that is not explicitly listed in KEEPFILE variables.
* The main root tree generated from the package set is broken in to * The template language should make common actions easy and obvious.
/usr for the install.img and everything else for the initrd.img. - Avoid 'runcmd' - add new builtins instead!
This is configurable through configuration files since we will - Corollary: It should be easy to extend the template runner
always have exceptions.
* Static data such as files we need to place in /etc in the images or * Image configs should allow custom commands/scripts
other control files are stored in /usr/share/lorax and copied in to - If you already have a bunch of kickstarts/Ruby/whatever for setting up
the image staging tree. images, you should be able to use that too
The approach of taking what the packages give us is a decision to make * Lorax should be usable as a script or a (python) library
maintenance of the image building tools easier. Whatever the packages lay
down should be sufficient for the installation images and we shouldn't
have to have our own list of files to keep and library gathering routines.
Let the packaging tools figure that out.
The whole tool is written in Python with a driver program ("lorax"), but the
actual logic for the program is in the pylorax module. The idea behind this
is that tools such as pungi can potentially import pylorax directly and not
have to run the command line tool to do image generation work. That is,
pungi can use lorax programatically.
This tool is still in the early stages of development (Sep 2008) and patches
and comments are welcome.

21
TODO
View File

@ -1,12 +1,13 @@
- Finish rewriting the code in rewrite/ ### Definitely do these:
- Have pylorax extend YumBase rather than invoking yum independently, we want - Write man pages for the included executables
to be able to take in a YumBase object from other things, such as pungi - Write a templaterunner script
- Write a man page for lorax
- Hook lorax up to pungi (provide Jesse with a patch) ### These might be good ideas:
- Support a verbose output mode (and disabling it)
- Make sure we are root when executed
- If we have to be root, should lorax be in /usr/sbin ?
- Use OptionParser instead of getopt (?)
- Create a Lorax class that can be used directly by pungi
- Move conf hash table to something more object-like - Move conf hash table to something more object-like
- Merge treeinfo and discinfo stuff in to InstRoot class - Merge treeinfo and discinfo stuff in to InstRoot class
- Port OptionParser code to ArgumentParser
### These are some longer-term things:
- Keep all build config files in one directory
- Move everything in Lorax.{configure,run}() to config files/templates
- Better debug output (esp. for tracebacks)