Description of problem:
There's a large degree of overlap between package groups and comps.
The default groups aren't end-user oriented and hence tend to be
unpopular for use outside of rpm itself. Comps is more end user
focused and hence popular for end user package install tools. But
there's no real reason why they couldn't be the same thing, allowing for: 

* consistency between group names used in RPM and the various tools
than run on top of it 
* the ability to have packaging tools easily include third party
packages. r-c-p could, for example, include third party apps within
its existing groups allowing users to easily uninstall such apps. Or
one could create package browsers for up2date that use a r-c-p style
frontend to help users find useful software to achieve a task by
browsing simple categories like like r-c-p does - for packages on all
the different kinds of repository.
* a chance to review the existing  rpm group names and come up with
something more end user focused (like the existing comps names)

Version-Release number of selected component (if applicable):
rpm-4.2.1-4.4
How reproduci
ble:
Always

Steps to Reproduce:
1.Wish r-c-p could easily integrate arbitrary third party packages
without having to rebuild a comps file each time
2.Wish RPM group names were more end user focused. A user coming from
a Windows background might find it difficult to to guess that a web
server is installed from 'System Environment/Daemons' as opposed to
'Servers/Web Servers' and the like. Likewise many desktop users might
not realize their office suite is 'Applications/Productity'
application ass opposed to the simpler comps-style group name
'Office/Productivity'.

Additional info:
Basically, the r-c-p guys got their groups system right, and rpm
should update its own currently seperate groups to reflect these.