New Comps Groups

[Jeremy Katz]

On Thu, 2006-11-30 at 23:18 +0100, Nicolas Mailhot wrote:
> Le jeudi 30 novembre 2006 à 16:11 -0500, Jesse Keating a écrit :
> > On Thursday 30 November 2006 14:46, Nicolas Mailhot wrote:
> > > Actually, if I had to redesign the comps model (which probably needs to
> > > be done someday) I'd aim for something like this:
> > 
> > Yeah, because that's easy for a packager to know where to put things...
> 
> It *does* make it easier for packagers. An individual packager only
> needs to add one <package name="mypackage"/> block for each of his
> packages, fill it with references to all the categories the package
> belongs to, and he's done. For example:

And then if a third-party wants to modify the groupings, they have a
massive amount of work to not only define new groups but also go through
and either change every package or categorize every single package.  In
contrast to today where it's actually pretty simple to write a new comps
file with your own set of groups and the packages you think belong to
them.

[snip]
> All the complex application policy stuff happens in the profiles, and
> it's not something most packagers care about:
> 1. every FE comps addition I've seen so far has optional state,

For existing groups, this is true.  And that's mostly to keep
consistency of what you get before and after the initial install.  But
when Extras has a whole new group of packages (XFCE for example), there
definitely are packages that are default... even some that are
mandatory.  Because they are what *define* XFCE.  Nothing in Extras can
"define" GNOME right now, because if so, there would be no way to get a
"complete" install with GNOME from CD (ie, just Core) -- therefore,
everything is default or optional.

> 2. the current groups are inherited from FC 

So are lots of things; that doesn't make them automatically bad :)

> 2. and we're seing fierce opposition to adding the groups FE
> contributors propose

The fierce (if you want to call it that) opposition is to blindly adding
groups without thought to what end-users are going to be taking
advantage of them.  Because that's exactly who comps is targeting.
Maybe being less stringent and adding less "end-user interesting" groups
in the Development category is okay.  But adding new groups should
always be an exception case with justification; otherwise, you end up
with too many groups for browsing to be reasonable.

> What I'm actually proposing is :
[snip lots of XML]

Like I said earlier in the thread, don't start with "what should the
file look like" -- it's ultimately not interesting.  The real question
is what the user experience should be.  You can't go from random file to
a sane UI; you have to start with the UI and then get to the file format
based on that.

Jeremy