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
Attachment:
pgpGBNiKdJUv4.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
