On Fri, 2007-01-26 at 22:12 +0000, Will Woods wrote: > Hi folks, > > In the course of messing with various installer tools, I've ended up > writing some python code that reads and writes an XML metadata file that > is (basically) an easily-parsable superset of .discinfo. > > A quick overview of the concepts involved here, from the top down: > > A "compose" is, basically, an entire distribution - all the installable > trees for all the various arches, plus iso sets, plus maybe some SRPMS > and debuginfo packages that go along with them. I suppose I could rename > this to "distro" but we've been using this terminology for so long that > it's just stuck. > > A "tree" is a directory layout with all the packages and images you need > to install from. > An "isoset" is (surprise!) a full set of isos that make up the > distribution. > > Okay, here's some examples. The tool that does the composing (pungi, > distill, etc.) should create .compose.xml in the top-level of the > compose dir. That file looks approximately like this: > > <compose id="rawhide-20070122" time="1169485348"> > <debug arch="i386">development/i386/debug</debug> > <debug arch="x86_64">development/x86_64/debug</debug> > ... > <source arch="i386">development/source/SRPMS</source> > <source arch="x86_64">development/source/SRPMS</source> > ... > <tree arch="i386">development/i386/os</tree> > <tree arch="x86_64">development/x86_64/os</tree> > </compose> > > This defines the id of the compose (which should be unique for each > compose, and would be nice if it was human-understandable like this one) > and a timestamp that lets you know when it was created. > > Really this file just exists to tell point you to the actual contents of > the compose, and where it all lives - there's debuginfo packages here, > sources here, trees here, and so on. Later we should also have: > <isoset arch="i386">development/i386/iso</isoset> > > Each of these items points to a directory where another xml file will > have further information - a "tree" directory will contain a file named > ".tree.xml", ".isoset.xml" for isosets, etc. > > So here's an example of tree.xml: > > <tree id="1169482851.57"> > <compose>rawhide-20070122</compose> > <family>Fedora Core 6.89</family> > <version>6.89</version> > <time>1169482851.57</time> > <arch>i386</arch> > <file type="kernel">images/pxeboot/vmlinuz</file> > <file type="initrd">images/pxeboot/initrd.img</file> > <file type="boot.iso">images/boot.iso</file> > </tree> > Finally there's a list of important files that other applications might > like to know the location of. For my purposes, those three files are the > ones I care about - other applications might want other file items to be > included here. This doesn't work for architectures where we have multiple kernels and compose a hybrid boot images (ppc, sparc possibly) to work with all of archs. You might want to have some sort of flavour in the file section to allow multiple entries. Assuming this is meant to be used by the iso generating code - see the mk-images.* scripts in anaconda/scripts The other really useful thing for the isoset would be to contain the total number of images in a set, at the moment we hard code this and if we intend for lots of spins of Fedora with different package set that's a bad plan. Paul Paul
