On Wed, 26 May 2004 10:30:12 -0400, Brad Smith <brads@xxxxxxxxxx> 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
