2006-10-09 19:06:00 +00:00
|
|
|
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
|
2006-10-10 04:00:02 +00:00
|
|
|
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.
|
2006-10-09 19:06:00 +00:00
|
|
|
|
|
|
|
|
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.
|
2006-10-10 04:00:02 +00:00
|
|
|
|
|
|
|
|
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.
|
