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.
comps groups and rpm groups have different uses. E.g. comps groups can be rearranged w/o rebuilding the package. This is not true for rpm groups.