[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: a replacement for .discinfo?

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

[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?


Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]