New Comps Groups

[Nicolas Mailhot]

Since I realise the rationale for the proposed format was not as evident
as I thought, here is is.

A.

Current comps puts packages directly in application (anaconda, yum)
groups. The problems I see there is :
- different apps need different levels of grouping (anaconda GUI needs
small usual groups, yum/pirut/kickstart more complete view of what's
available, repoview exhaustive package categorisation)
- creating independant comps for each app is not sustainable long term,
the repo is too big and packagers will go crazy at the n-th comps that
requires them to declare again an app is in multimedia/gnome/whatever
- each time the target UI of a tool changes we need to re-classify from
scratch
- if we go with multiset releases, each app will want a comps per set,
which will only compound the problem

So we need to declare "blocks" of packages to avoid manipulating package
lists directly. Apps define "groups" (what they expose in their UI) as a
composition of "blocks" and individual packages. The compostition rules
can have a multi-release life, there's no need to change them every time a
package is added to the repo

B.

"blocks" can not be infered from smart google-like queries - we just don't
have the wealth of info in package metadata google finds in web pages.
OTOH we do have someone responsible for each package. So pre-google manual
tagging is both necessary and feasible.

There is no reason for the number or granularity of "blocks" to cause
problem for comps-using apps. They can just ignore the "blocks" not used
in the composition rules they've defined for their groups.

C.

Now we don't want packagers just to associate random keywords to packages
(if only because of multiple spellings), so we start by defining the
keyword vocabulary our comps will use. That's my "categories". Initial
vocabulary can just be a 1-1 mapping of FC/FE groups.

Maybe as Toshio suggested a flat one-level category organisation is not
good enough for repoview, so we can define hierarchie*s*

<category name="foo">
 <!-- usual text localised metadata -->
 <description>...</description> <!-- ... -->
 <!-- subcategories -->
 <category ref="fooish"/>
 <category ref="bar"/>
</category>

This is project-level stuff driven by the needs of comps users, and
regulated by YAFCO

D.

Now we can populate the category trees with packages. We could put package
refs directly in categories like current packages-in-groups, but IMHO that
would only confuse responsibilities. I'd rather have individual

<package name="foo">
 <category ref="fedora"/>
 <category ref="bar"/>
</packages>

blocks 100% under the responsability of individual package maintainers,
since that makes clear they're not supposed to mess with the distro
classification policy by themselves

E.
Once that's done apps can define groups as big/small/complete as they
need, just by combining the categories the project provides

<profile>
 <group name="whatever">
  <!-- usual text localised metadata -->
  <description>...</description> <!-- ... -->
  <content>
   <!-- as many categories as you want, if big groups are needed just make
a long category/package ref list or target categories with lots of
subcategories, if small groups are needed just shrink the list -->
   <category ref="a"/>
   <package ref="b"/>
  </content>
</profile>

Astute users will have recognized the principles used by ant filesets and
the relax-ng spec. There's many smarter ways to use XML than the current
element withing elements hierarchical approach comps uses.

Regards,

-- 
Nicolas Mailhot