Re: groups storage - some common ground here too?

Jeff Licquia <[email protected]>
Newsgroups gmane.linux.rpm.metadata
Message-ID <[email protected]>
On Mon, 2003-11-03 at 01:06, 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?

Yup.

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

Strictly speaking, Debian's task system isn't used by apt, though some
of the task information is stored in the apt metadata.  Other tools
(tasksel, specifically) grab task information from multiple sources and
assemble them into a coherent whole.  Thus, I imagine Debian would write
a "tasksel-alike" to handle this metadata.

As part of my work on apt-anaconda, we've already gotten a good way
towards something like this with the current comps.xml, so basing the
new groups file on comps.xml would be a good idea.

We might also be able to pry a DTD for comps.xml out of Red Hat this
way. :-)

> 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 certainly don't have a problem with it as long as it's optional.
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.