On Mon, 2007-01-29 at 11:08 -0500, Jeremy Katz wrote: > Will Woods wrote: > > 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. > > There's quite a bit more here than .discinfo and not most of the things > which are currently in .discinfo. .discinfo definitely needs to be > reworked (for one thing, half of the lines aren't relevant with the yum > backend much less when backends can be generic), but I'm not entirely > sure that this is the direction to go. Hm. Can you elaborate on the backend stuff a bit? It seems obvious that (for instance) the 'pixmaps' entry is useless, but are there things that would be helpful for yum? What considerations are needed for other, future backends? > For one thing, we're going to have to parse this in the loader; I'm not > sure I want an XML parser there. Hm, yeah. I certainly don't want to make the loader have to parse XML. > The other thing is that it feels like it's modeling a bit > closely exactly how we currently do things instead of some of the > directions that things are moving in with the land of many Fedora spins. Right, this file format was designed just to handle junk we currently have. I'm hoping we can figure out a way to redesign it so it makes sense for the future as well. So, upon reflection.. forget about the tree.xml altogether. Here's a different idea - a slightly improved version of discinfo that uses key-value pairs, and *also* contains all the info I wanted to put in tree.xml: [wwoods@metroid os]$ cat .distinfo family: Fedora variant: Desktop version: 6.90 arch: i386 timestamp: 1170104239.562016 composeid: 20070129.1 disc: 2/3 packagedir: Fedora This is really just stuff that's already in .discinfo, just a bit easier to read/parse. A couple notes: 'composeid' is, again, just something that each of the trees in a compose will share. Mostly this is useful to correlate common information that the trees will share; for example, a typo in anaconda on i386 will probably show up in ppc and x86_64, if they're all from the same compose. Without a composeid, there seems to be no easy way (short of comparing package sets) to determine if tree A and tree B were built from a common set of packages. The 'disc' item might need to be reconsiders by someone who understands that stuff better. Heh. Anyway, in addition to this basic info we can also add entries for things that applications will want to find: boot.iso: images/boot.iso stage2.img: images/stage2.img minstg2.img: images/minstg2.img isoboot: isolinux/vmlinuz isolinux/initrd.img netboot: images/pxeboot/vmlinuz images/pxeboot/initrd.img xen: images/xen/vmlinuz images/xen/initrd for ppc trees we might have: isoboot-ppc32: ppc/ppc32/vmlinuz ppc/ppc32/ramdisk.image.gz isoboot-ppc64: ppc/ppc64/vmlinuz ppc/ppc64/ramdisk.image.gz netboot-ppc32: images/netboot/ppc32.img netboot-ppc64: images/netboot/ppc64.img Does this make sense? It's got all the information *I* care about, but is this a useful improvement by other people's measures? If not - what's missing? -w
Attachment:
signature.asc
Description: This is a digitally signed message part
