Re: groups storage - some common ground here too?

On Mon, 3 Nov 2003, seth vidal wrote:

> I was thinking about the other files outside of just package metadata in
> the lists and I was wondering about grouping metadata. Right now yum can
> read the comps groups xml file, as can redhat-config-packages. I know
> apt uses the idea of task-oriented groups and I know rc has a grouping
> mechanism as well. Would there be any interest in seeing if we could
> agree on a groups format as well?
> 
> I was proposing to use the current comps.xml format
> (http://fedora.redhat.com/projects/anaconda-installer/comps.html) that
> is being used in anaconda right now(comps.xml - but just the grouplist
> section). With a few modifications:
> 
> 1. add more flexibility to the 'types' for the packagereq's, groupreq's
> and metapkgs
> 
> 2. maybe remove the metapkg concept altogther as it's distinguishing
> characteristics from a groupreq is not immediately obvious
> 
> 
> Thoughts? Would this be flexible enough for what apt's Tasks do? What

I wouldn't call "apt's tasks" particularly flexible since they're just
empty packages with dependencies. Might work better when carefully
handcrafted (and in presence of Suggests and such) but the way I've been
creating task- packages for RHL - automatically generating from comps.xml,
being the lazy shmug I am - the task packages grow up to be hideous
monsters and are more of a PITA than anything else. Using current 
comps.xml more-or-less as is fine by me, I already wrote the Lua 
groupinstall thingy even :)

> about for red carpet? Clearly, these groups are not, typically,
> assembled from metadata stored IN a package but it seems like everyone
> uses this sort of functionality. Would it be worthwhile to work on
> defining this now?

I don't see why not... like you said everybody is using similar 
functionality one way or the other.

	- Panu -