New Comps Groups

[Paul Howarth]

Nicolas Mailhot wrote:
> Le lundi 27 novembre 2006 à 15:58 -0500, Jeremy Katz a écrit :
>> 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]
> 
> But the entire point is unless packages show up in comps, we have no
> idea if they're missing because they should not be exposed or because
> someone forgot to think about it.
> 
> explicit "this package is in a group most users don't care about" is
> very different from "this package is not in any group, so probably users
> do not need to see it"

Can't the package checking problem be solved by adding packages that are 
deliberately not intended to be in comps either to a group that is 
defined not to show up in the UI (that might need some extra work on the 
schema and the tools though), or in a completely separate file from the 
comps file that exists for the purpose of doing this checking?

Paul.