New Comps Groups

[Nicolas Mailhot]

Le jeudi 30 novembre 2006 à 21:26 -0500, Jeremy Katz a écrit :
> 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.

Nonsense. Nothing stops 3rd-parties to use their own file, and this file
can use as many categories and group as they want (indeed since content
blocks take packages in addition to categories as arguments they can
even ignore categories altogether and write groups with package lists
just as today).

The obligation to categorize every package BTW is a Fedora-level thing,
I don't think the tools would mind it if a 3rd-party comps only
categorised part of the repo.

The difference with now is they can have many pre-defined building
blocks and classification axis to compose their groups, instead of ahing
to start from scratch because the Fedora comps only ships the group
granularity Fedora anaconda wanted.

You can even write rules like "I want every package Fedora considers
member of foo category, except bar and with baz"

<content>
  <and>
   <category ref="foo"/>
   <not>
     <package ref="bar"/>
   </not>
  </and>
  <package ref="baz"/>
</content>

(though now that I think of it binary categories are too limitative,
valued categories can be useful too)

<package name="foo">
  <category ref="user-rating" value="80"/>
</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.

You can still do this

> [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.

You still have most of your packages optional, and I've shown how to
define content of special kinds without re-enumerating all the packages
in one category

> 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.

That is overly simplistic. You don't start with anaconda UI, define a
matching format, and hope all things go well. You start with anaconda
+yum+pupplet+repoview needs, how Fedora is organised, and then you
define a format able to match all your tools needs (without undue
duplication) and the process you'll use to create the file (who can
define what element at what stage)

All the current complaints about comps are about its anaconda-centric
view and the resistance to make it useful to other tools.

In the FCE merged world BTW people are talking about making topic CD/DVD
sets. Currently that would require rewriting separate comps from scratch
for every install set. Instead in a world were categorization and
application view/profile grouping were separate, you could use a single
fully categorised package pool as source and only care about how each
install needs to combine the existing categories

-- 
Nicolas Mailhot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: Ceci est une partie de message num?riquement sign?e
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061201/82cbc10d/attachment.sig>