http://fedoraproject.org/extras/4/i386/repodata/

Jeff Spaleta jspaleta at gmail.com
Thu Jul 14 18:14:21 UTC 2005


On 7/14/05, Matthew Miller <mattdm at mattdm.org> wrote:
> Yeah; the existing groups could be recogized by the way they contain a "/"
> and dealt with as legacy. Or, maybe it wouldn't be considered a tag unless
> there's more than one separated by a ",". Or just let 'em be tags that would
> generally be ignored. So many possibilities. :)

> I could be convinced, but on the contrary, I don't see any pressing need for
> it *not* to be, given a better design than the old "GROUPS" list.

this is unwieldly and doesn't scale out well to 3rd party repos who
need to redefine groups that a package belongs in without having to
rebuild any packages.

yum groupinstall "Crap for Jef's lan"   works because I have a mangled
comps.xml file in a local repo and i don't have to rebuild any rpms. 
Or in a more realistic case  a group definition like "Software for
Physics 403"  sitting in a comps file on a local mirror of a school so
all students taking that class can groupinstall all the software for
that class in one pass on a fedora system. Some of it from Core or
Extras some of it from a local repo. This group definition makes no
sense inside an rpm spec because the group is situational for the
school for a limited period of time and not something that needs nor
should be exposed to all users of all fedora packages.  There is no
way you can expect the maintainers at build to try to classify all
possible structures at build time.  But, if we put the editorical
information about groupings into easily editted comps files... those
comps definitions can be extended or overwritten locally as the
situation demands... no need to touch the rpms.

Grouping and categorization into components can and will be editorial
in nature. Its not unlike playlist creation.  On the magical ipod,
having my wife and I both create a playlist named "Driving Music" 
would result in 2 strikingly different sets of songs.  tags in songs
are mostly informational... playlists are highly personalized and
highly situational.
Sure having tagging information in the rpms is useful... but its not
practical to demand all categorization information exist in rpms..
especially since retagging rpms is not exactly easy to do. For rpms,
categorization needs to live outside the packages, so that situational
needs can result in new editorial information encoded in comps files
as needed.  The unedittable group tag just isn't flexible enough to
provide a mechanism for dowstream repos to redefine groupings to
better serve their local users.

-jef




More information about the fedora-extras-list mailing list