New Comps Groups

[Jesse Keating]

On Tuesday 28 November 2006 14:31, Nicolas Mailhot wrote:
> The point is, people can classify properly packages, and apps choose to
> show more or less groups depending on the target audience.
>
> For example repoview will typically show all groups, anaconda the most
> important ones, yum something in between

But your hiding the package so NO tool will see it.  What is the point there?

> > You're going to still have to answer the
> > question at review time,
>
> Actually one of the big arguments of the comps vs rpm group crowd was
> that comps classification could happen at a different level than the
> packaging. If we want to bolt compsifying so hard to packages at review
> time, I don't see the point of choosing an out-of-package metadata
> format

I'm the one making that argument.  Package grouping is really dependent upon 
the people putting together the repository and the metadata.  I want to be 
able to take the built packages, put them in another repo with a different 
comps file that groups them how _I_ see fit, and how my users will see fit, 
which may be vastly different from how upstream Fedora sees fit.  Forcing it 
into the package itself locks downstream into one narrow view of the package 
grouping.

> > Adding it into comps into a hidden view just is one more
> > complicated step, makes comps generation time that much longer, and
> > provides no improvement to end users.
>
> I can only strongly disagree with every single statement in this §
>
> > I'm also using comps as a method to determine what packages to gather up
> > and put onto a CD.  It really doesn't make sense to put packages on CDs
> > that aren't installable options, or aren't deps of installable options.
> >  My tool reads comps for packages, then depsolves, and then spins CDs
> > based on the results.
>
> Well your tool only needs to learn selecting a group subset, which
> you'll have to anyway, as the Fedora universe is quickly moving out of
> single-disc space.

What file my tool uses in the future is to be decided, but the idea now is 
that you can create your _own_ comps file and group things how _you_ want 
them grouped for _your_ spin of Fedora.  Yes, there will still need to be 
something of a 'master' comps file so that tools that choose to point back to 
the Fedora freeverse of packages will still get proper groupings, but even 
then just dropping all packages as hidden in comps HELPS NOTHING!

-- 
Jesse Keating
Release Engineer: Fedora
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061128/e1c13064/attachment.sig>