41 lines
		
	
	
		
			2.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			41 lines
		
	
	
		
			2.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| Policies for initrd.img and install.img image generation.
 | |
| 
 | |
| 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:
 | |
| 
 | |
|     * Configuration files control the list of packages to make images with.
 | |
| 
 | |
|     * 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.
 | |
| 
 | |
|     * 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.
 | |
| 
 | |
|     * 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.
 | |
| 
 | |
| 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.
 |