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 -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
