New Comps Groups

[Jeremy Katz]

On Thu, 2006-11-30 at 20:51 +0100, Nicolas Mailhot wrote:
> Le jeudi 30 novembre 2006 à 13:45 -0500, Jesse Keating a écrit :
> > On Thursday 30 November 2006 12:29, Toshio Kuratomi wrote:
> > > I would say that apt and smart's UI would not suffer from a
> > > migration to comps provided that comps lists all the packages in the
> > > repository.
> > 
> > Why do all packages have to be listed in comps?  The grouping metadata can 
> > list packages being in some groups, and then if a package isn't in any group, 
> > the tool (apt/smart) could represent that as 'Ungrouped' or however you want 
> > to phrase it.
> 
> Why to you want to impose the policy of one user of this file (anaconda)
> on others ?

Because the file exists to provide the metainformation needed for a
specific UI -- that used by anaconda and pirut.  

> Defining groups for anaconda use and lumping everything else in an
> anaconda-does-not-care limbo is not the answer. 

It's not anaconda doesn't care, it's that *USERS* don't care.  There
definitely are groups that _are_ end-user interesting that aren't
present.  And when those come up, it's easy.  But this crusade to list
every package in comps is explicitly _not_ what comps was ever intended
to be.  

> The answer is to categorise everything, and let apps define the
> filtering they want separately.

And what provides the information as to whether something should be
filtered?  Hard-coded in anaconda?  That goes great with doing
derivatives...

Jeremy