How important is comps.xml to us these days? Which packages should be in comps.xml and which not?

Kevin Fenzi kevin at
Wed Sep 24 16:03:17 UTC 2008

On Mon, 22 Sep 2008 12:31:29 -0700
a.badger at (Toshio Kuratomi) wrote:

> Thorsten Leemhuis wrote:
> > On 22.09.2008 08:49, Alex Lancaster wrote:
> >> Ideally this would be done either as a mandatory part of the
> >> original CVS import request (a field could be added, with an
> >> opt-out provision if really not appropriate for comps), or added
> >> interactively by the maintainer via PackageDB as I suggested in
> >> the feature request here:
> >>
> > 
> > Hmmmm. How much does the pkgdb know about the binary packages that
> > get build from the source packages? Not much afaics, as the pkgdb
> > mainly (only?) works with the (source) packages and not the ones
> > that get build from it -- but in a proper comps.xml we need to list
> > the binary packages, as a user might want to select the packages
> > (rpms) foo or bar that both might get build from the package (srpm)
> > foobar.
> > 
> >> Having to manually update the comps.xml file for multiple releases
> >> is painful, error-prone and probably why most package maintainers
> >> ignore it, especially since it is not enforced in package reviews.
> > 
> +1

Yeah, agreed here too. 

> So here's where I'm at WRT binary packages.
> We have too many apps interested in doing only a subset of the work in
> this area.
> There's amber which is going to provide an end user view of
> applications (rather than packages) with categories and tags.
> There's Fedora collection which probably won't have a permanent data
> store of its own. There's PackageDB which oculd be expanded to handle
> this (it has tables for binary packages but is unfilled with data).
> There's koji which touches every binary package, consumes and
> generates comps files. 

I thought it was mash that consumed and generated the comps files?

> There's comps.xml which is the master store
> for this information right now.  There's repoview which provides a
> static interface to binary packages and comps on the gold repo but
> not yet updates -- if it is updated to work on updates, that will
> require bodhi to write out the files.
> So:
> 1) In which app should the canonical storage for this reside?

Perhaps we could get together a meeting of koji, mash, bodhi, pkgdb
folks and hash this out?

> 2) What interface do we want to put on top of the storage?
> 3) What apps will need to pull data from there once we have it?

I think 2 and 3 will depend on where the data ends up being stored. 

> -Toshio

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <>

More information about the fedora-devel-list mailing list