New Comps Groups

[Christian Iseli]

Trying to step back a bit here...

Things I'd like to do from a user point of view:
- see what apps are available for performing some tasks, e.g. create
  video DVD, develop and test that new python package, ...
- have an easy way to select the packages I find useful and install them

Things I'd like to do from a packager point of view:
- attach some grouping info to my packages, e.g., this package is a
  bioinformatics tool, it is meant to run in a KDE environment, ...
- be able to tell e.g. fellow bioinformaticians: just do a
  "yum groupinstall bioinformatic-tools"
  and you will be good to go
- not have to enter redundant info into many different files

Things I suspect a release creator would like to do:
- define a set of packages that should get installed when the user
  chooses a certain type of install, e.g.:
  o KDE desktop
  o GNOME desktop
  o web server
  o barebone minimal

Things I'd like to do from a QA point of view:
- make sure all packages get consciously assigned to the proper
  group(s)
- easily verify the correctness of the comps.xml file


The current state of things is that the Group tag in spec files is not
flexible enough, and its location within the spec file not appropriate
for many of the above goals.

The current state of things is that the comps.xml file is the only
mean we have right now to deal with the above goals.  Maybe it is not
well suited either to fulfill all of them, but that's all we have
ATM...  It is used by anaconda, pungi, yum, pirut, ...

What I'm wondering is whether:
- adding some useful, task oriented, groups to comps might make for a
  better user experience
- maybe extending the comps file, as proposed by Nicolas, is enough
  until a better solution is defined and implemented
- having hidden "only used in support of another package" packages in
  comps is really that bad
- comps might completely disappear once the package database is up and
  running

					C