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

Update TODO and POLICY to reflect the current state of things

Browse Source
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
for generating the boot and install images and tree data files. First, the
main ideas:
Some design precepts:
* 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.,
we used to have KEEPFILE variables in upd-instroot), we now take what
the packages lay down and do a minimal tree scrubbing (remove docs,
for example). This is customizable through configuration files
because we will always have exceptions. But the policy in lorax is
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.
* Templates should be brief but expressive.
- Don't make the user maintain huge lists of files/packages
(do filename globbing and brace expansion, resolve package deps, etc.)
- Provide commands that allow blacklists/exceptions
(e.g.: removefrom PKG --allbut FILE FILE...)
* The main root tree generated from the package set is broken in to
/usr for the install.img and everything else for the initrd.img.
This is configurable through configuration files since we will
always have exceptions.
* The template language should make common actions easy and obvious.
- Avoid 'runcmd' - add new builtins instead!
- Corollary: It should be easy to extend the template runner
* Static data such as files we need to place in /etc in the images or
other control files are stored in /usr/share/lorax and copied in to
the image staging tree.
* Image configs should allow custom commands/scripts
- If you already have a bunch of kickstarts/Ruby/whatever for setting up
images, you should be able to use that too
The approach of taking what the packages give us is a decision to make
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.
* Lorax should be usable as a script or a (python) library

21
TODO
View File

@ -1,12 +1,13 @@
- Finish rewriting the code in rewrite/
- Have pylorax extend YumBase rather than invoking yum independently, we want
to be able to take in a YumBase object from other things, such as pungi
- Write a man page for lorax
- Hook lorax up to pungi (provide Jesse with a patch)
- 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
### Definitely do these:
- Write man pages for the included executables
- Write a templaterunner script
### These might be good ideas:
- Move conf hash table to something more object-like
- 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)