New Comps Groups

[Jeremy Katz]

On Mon, 2006-11-27 at 14:19 -0800, Christopher Stone wrote:
> On 11/27/06, Jeremy Katz <katzj at redhat.com> wrote:
> > On Mon, 2006-11-27 at 21:52 +0100, Nicolas Mailhot wrote:
> > > Le lundi 27 novembre 2006 à 15:33 -0500, Brian Pepple a écrit :
> > > > On Mon, 2006-11-27 at 13:24 -0500, Bill Nottingham wrote:
> > > > > We already have a 'package search' interface for finding packages - is
> > > > > listing 100 (or however many) python-* packages better than this? In
> > > > > what way? Are they not getting pulled in for dependencies when necessary?
> > > >
> > > > I'm in agreement with Bill on this.  Pretty much all the python-*
> > > > packages should be pulled in as dependencies.  Am I missing something
> > > > here?
> > >
> > > It's pretty much impossible to autodetect missing comps entries unless
> > > every package is systematically put in comps. No autochecking means low
> > > QA.
> >
> > But the entire point is that everything _SHOULDN'T_ be there.  If so,
> > then it's no better than a list[1]
> 
> How is adding a half dozen new groups to Development in comps going to
> reduce comps to be noting better than yum list '*'?

The problem is that you're using the argument of "all packages need to
be in comps, so we need to add groups" when comps was _never_ intended
to be an exhaustive list of every package.  

Trying to solve "forgotten" packages by making _every_ package be listed
is a losing battle and makes comps far less useful than it was intended
to be.  You'd be better off solving that problem with a) include it as a
step in the review process and b) integration with the push scripts to
provide notification/questioning when a new package is added to the
repository and isn't listed in comps.

Jeremy