New Comps Groups
Jesse Keating
jkeating at redhat.com
Tue Nov 28 19:52:58 UTC 2006
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>
More information about the fedora-extras-list
mailing list