RPMGroups -- time to refresh? [was Re: Question about how to announce packages]

[Jeff Spaleta]

On Sun, 08 Aug 2004 19:51:48 -0400, seth vidal <skvidal at phy.duke.edu> 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