On Sun, 08 Aug 2004 19:51:48 -0400, seth vidal <skvidal@xxxxxxxxxxxx> wrote: > I think for the purposes of core and to some extent for collections w/i > extras we'll need some way of describing groups comprised of specific > packages. This is what comps.xml has done for a while for rhl/fc but > comps needs to be freshened up a bit to include: > - archs (sorry jeremy) > - possibly partial or complete versions > - more granularity of group requirement > > This is part of the discussion we've had wrt to the xml metadata for rpm > repositories. > > This works not from w/i the package but from the outisde, of course, and > it would allow a per-repository basis to describe groups of packages. This is a really complicated issue. I've had several versions of this argument with several different people. I of course, being the evil sob that i am, have taken different sides of the argument at different times. Right now I see at a mimimum 3 different explict package groupings being used inside the distribution: 1) rpm group tag 2) comps.xml 3) The applications menu structure. Right now each one of these ways of organizing packages serves different uses. comps.xml and similiar is clearly targetted as a way to help people install bundles of packages for large chunks of 'recommended' functionality. If we really want to talk about a future where community can redefine collections inside Fedora, something as flexible as comps.xml must continue to exist to allow for people to play with alternative ways to groups packages outside the strict dependencies inside a package. Right now, I would say comps.xml isn't being used so well as a way to browse individual packages for install or for removal. Because the comps.xml approach is very flexible and multiple repositories can layer their groupings, i can't imagine it would be all that difficult to build an alternative comps.xml that represented several trove like views to make browsing packages for different criteria easier. Right now the applications menu organization is different than both rpm group tag and comps.xml. I fear that continual debate about how to name menu items is going to lead to a continual disconnect between the strings in comps.xml and the textual listings in the menus. I think there is room here to build an alternate comps.xml that mimiced the applications menu groupings as a useful tool for users. Want to find a specific graphics application or system tool? Use the comps.xml that groups applications exactly like the application menus structure so you can browse the application menu structure looking for applications. With enough tequila.. i can even imagine some sort of tool that could automate generation of a applications menu mimic that took into account local menu structure changes. rpm group tag currently is a search for package by package functionality. You can ask questions like 'what are all the libraries packages installed on my system.' Well okay to be honest the rpm group tag current doesn't serve much of a use at all, very rudimentry search by function really. The rpm group tag formatting/syntax would have to be greatly expanded to be useful as a fine grained searching. And even then its a nightmare to think about if you are going to allow for locale specific strings....a nightmare. And sort of comps.xml file approach to trove listing creation will be able to provide for locale specific listings. -jef
