On Mon, 2006-11-27 at 14:19 -0800, Christopher Stone wrote: > On 11/27/06, Jeremy Katz <katzj@xxxxxxxxxx> 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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
