rpm groups and fedora: a modest proposal

[Jeff Spaleta]

On Wed, 26 May 2004 10:30:12 -0400, Brad Smith <brads at redhat.com> wrote:

> 
> That works great for you, but what about the noob who doesn't know how
> to do that and doesn't need (yet) another component to deal with in the
> Fedora's already complex package management system.

Then we spend the time to fix the noob facing components to use comps.xml files
provided by noob friendly repositories. Re-inventing the group tag and
arguing over what exactly the right group tag names should be is a
huge waste of effort.
comps.xml provides flexibility... 3rd party public repos and intranet repos
can define the groupings that make sense to them without having to
pretend like we are ALL going agree on how best to codify a group
naming scheme. Who cares if my personal repositories invents a new
package group just for plasma physics software....if the in distro
packaging tools aimed at a noob, see my comps.xml file and merge my
comps.xml file into a groups listing...problem solved. There is no
reason to think that Core has to pre-define every concievable grouping
for packages and force every concievable collection of packages that
are in use to abide by that set of names.

A sensible group naming scheme is going to be a continual work in
progress and shackling an evolving grouping standard into the package
building itself serves only to stagnate the discussion around group
naming into the future becuase you have to constantly worry about the
group names defined in packages you can not rebuild but must continue
to worry about.  Seperate it out...let the group naming scheme evolve
on its own seperate from actual package building. Let university
intranets define their OWN groupings in repositories that make sense
to them. Let 3rd party repositories choice to follow Core grouping or
to expand on grouping as they see fit. Don't pretend like everyone is
going to come to a consensous about how to group packages
together..its not going to happen. Don't try to pretend like the list
of package groups that make sense right now...will make sense 6 months
from now or a year from now..thats just asking us to have the same
fight about group names again in the future...over and over and over
again.

> I hope everyone can agree that the fewer external components we involve
> here, the simpler the process becomes and the fewer things can go wrong.
> With standardized Group info in the headers you don't have to deal with
> issues like users not having up-to-date *.comps.xml files, incomplete
> comps, etc.

I have very little faith that all packagers can agree on intuitive
naming scheme and stick to it more than 6 months....very little faith.
 At best you are going to force a naming structure on people that is
ill-fitting 6 months from now. We HAVE a set of standard names...they
aren't good enough hence...comps.xml. comps.xml is not going away, and
the group tag is not flexible enough to replace what comps.xml does in
terms of grouping groups into metagroups and to flag packages as
optional in one group but a default member in another group.  Given
that developer resources are the scarce commodity comps.xml has
already shown itself to be MORE useful in terms of installation and
metapackaging functionality than the group tag could ever hope to
be...without mentioning the locale support inherent in the comps.xml
file format which is non-trvially important. Burning brain-power and
developer cycles to think hard about how to bootstrap all of comps.xml
advantages back into a group tag in rpm, is wastefully indulgent.

> That said, you make a very good point about the advantage of an external
> file: It makes it simple for the user to group packages however he or
> she wants. So I think a compromise can be met by rescinding one of the
> points I made earlier: That it would be a bad idea to support both.
> 
> I suggest that we:
> 
> 1) Agree on a standard set of group names (and make sure at least most
> of the third-party maintainers are willing to conform to them)

Not going to happen. Everyone with a stake in defining a bettter set
of names are NOT going to agree..its going to be a long dragged out
fight...no point in starting it.
And there is no way to be comprehensive and account for ALL possible
future groupname needs.


> 3) Design all packaging tools (yum, system-config-package, anaconda,
> (apt?)) so that if a *.comps.xml, yumgroups.xml, etc file exists it
> takes precedence over the Group field, but if the package does not
> appear in an xml file, the Group field is used.
Screw that, make repos responsible for defining their own comps.xml
files and demand repos provide comps.xml files.  If repos want to use
the Group tag as an automated way to build their own groups...fine by
me..they can do so in a way that makes sense for them. Expecting tools
to fall back to a per package...maybe standard...maybe not...group
tag...no thanks....extra functionality in the tools means potentially
more bugs...and less testing.

> For all I know, step 3 may already be the way it works. Either way, it
> seems to me that while there are advantages to the external xml files,
> deprecating Group so that grouping data is kept there exclusively is
> going to open users up to yet another thing that can go wrong when
> managing packages, which is a Bad Thing.

The group tag can go wrong...dont even doubt it. Instead I say drop
the group tag...
drop the tag that each packager has to worry about conforming to a
"standard" they might not even know about. And deal with all the
grouping information at the repo level, so one person can be
responsible for keeping the grouping definitions for a repo in tact.



-jef