On Mon, 22 Sep 2008 12:31:29 -0700
a.badger(a)gmail.com (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:
>>
https://fedorahosted.org/packagedb/ticket/78#comment:1
>
> 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
kevin