63 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			63 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| FIST
 | |
| Fedora Install Spin Tool (Name could change at any moment)
 | |
| 
 | |
| This project is aimed at making a public / free tool to spin installation
 | |
| trees/isos of Fedora.  It will be written in python (for many obvious
 | |
| reasons).  Code style I hope will be of a simple "master" process that can
 | |
| call any number of subprocesses depending on a configuration set.
 | |
| 
 | |
| Thoughtspace:
 | |
| We'll need to do five basic tasks:
 | |
|   1) Gather packages from repos into a directory tree
 | |
|   2) Run anaconda tools (buildinstall) on said directory tree
 | |
|   3) Split tree into CD iso size chunks
 | |
|   4) Create isos of the chunks
 | |
|   5) Sanity check the tree
 | |
| 
 | |
| Gathering Packages
 | |
|   Using yumdownloader / reposync like code in combination with a comps file 
 | |
|   makes sense here.  We can define what we want at the top level and let yum 
 | |
|   depsolve the rest.  The tricky bits here are figuring out multilib stuff and
 | |
|   the uglyness that is noarch packages with ExcludeArch/ExclusiveArch crack.
 | |
|   We could skip over this by assuming that repos will exist that are pre-
 | |
|   populated with multilib/noarch safe packages and we just pull whats there.
 | |
|   There is some code in the Extras push scripts.  See also yum/comps.py for 
 | |
|   dealing with comps.
 | |
| 
 | |
| Running Anaconda Tools
 | |
|   These should be ran on the release it is releasing.  This means using mock
 | |
|   in some way, either make mock a req of the tool and the tool calls mock
 | |
|   or allowing the tool to run in userspace but suggest the tool get ran in
 | |
|   a mock call.  Some cooperation will need to happen with the anaconda folks
 | |
|   to make sure we're moving in the same direction they are wrt the tools we
 | |
|   would use.
 | |
| 
 | |
| Split Tree Into CD Size Chunks
 | |
|   This will be a fun task.  Really, I mean it.  Anaconda folks have made some
 | |
|   noise about making buildinstall take a flag to make CDs and do all the
 | |
|   splitting itself.  That would be handy, but it may not happen by the time
 | |
|   we need to do this.  Perhaps work on this part last, focus on the
 | |
|   installable tree stuff.
 | |
| 
 | |
| Create Isos of the Chunks
 | |
|   This is a pretty straightforward call to mkisofs.  There are some fun things
 | |
|   to consider when making isos for ppc(64) and possibly other arches that may
 | |
|   come to play.  Code here will need to be somewhat modular to allow for
 | |
|   different mkisofs calls per arch.
 | |
| 
 | |
| Sanity Check the Tree
 | |
|   This could/should be an ever growing set of post-tree build sanity checks.
 | |
|   Hopefully it'll cut down on brown paperbag trees sneaking out.
 | |
| 
 | |
| Organization
 | |
|   Each task set will be its own module.  Work on each module can be done
 | |
|   independantly and hopefully once functional it should be easy to tie them
 | |
|   all together (one ring to bring them all, and in the darkness bind them)
 | |
| 
 | |
| Making it all happen
 | |
|   There really is space for two tools, or something inbetween.  There is the
 | |
|   task of creating a repo of packages multilibbed up.  Think rawhide.  The
 | |
|   second tool takes packages from said repos and makes the install and CD set.
 | |
|   Working on the second tool first makes sense, as it can be used today with
 | |
|   existing Core and Extras repos.  Later, tool #1 can grow from #2.
 | 
