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

[Sean Middleditch]

On Sun, 2004-08-08 at 20:48, Jeff Spaleta wrote:
> 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.

Is comps.xml really that great?  One problem it seems to have is that is
must constantly be kept up to date with the latest package revisions. 
Wouldn't it be better to keep the group tag in the RPMs themselves
(possibly replacing the fairly useless group field in there now), and
let the comps.xml format merely override those for users with special
cases?

Then the comps.xml for Fedora Core might not change much at all; if a
new package is uploaded to the repository and is tagged as, say, being a
core GNOME app, it'll Just Work(tm).

> 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.

In this case, I think it would be a _lot_ better to just add a tag like
"PackageType."  It would be one of: library, application, tool, data,
documentation, debuginfo, development, core, etc.

If you then also added a tag like "RelevantTo:", you could mark all
documentation/debuginfo/development/data packages as relevant to the
particular application/tool/library packages, so you can do neat things
like ask the system to install all debuginfo packages for every package
already installed, remove all documentation packages, etc.

You can also do some nifty policy work.  For example, ask yum to always
try to Install vs Upgrade library packages.  One thing that's incredibly
retarded in Fedora is the way library packages with incompatible
versions of the library (and with different sonames even) always want to
upgrade the old package.  You are forced to constantly keep all
applications using the library in sync, which is just dumb.  Especially
when upstream may not have migrated to an API update.  Having to rename
packages a la Debian is a lot of work, if library packages were just
Installed instead of Upgraded, things should just work in most cases. 
Being able to make that kind of policy in the client side without having
to go repackage the entire distribution would make life a lot easier
both in testing and in actual usage.

> 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
-- 
Sean Middleditch <elanthis at awesomeplay.com>
AwesomePlay Productions, Inc.