On Wed, 2006-11-29 at 21:39 -0500, Jesse Keating wrote: > On Wednesday 29 November 2006 18:59, Toshio Kuratomi wrote: > > If we are making the RPM Group field optional in the spec file, then we > > have to allow equivalent information to be stored and retrieved from > > somewhere. In the Packaging Meeting, this somewhere was comps. If > > comps is not the place for it then we have a bit of a problem. > > The repodata itself can list the rest of the packages. The tool can list the > grouped packages, and packages that aren't listed in any group can fall > under 'ungrouped packages'. > "ungrouped packages" is horrible. If I'm looking for a python module to help me write an email signing plugin I certainly don't want to browse all the C libraries, command line tools, and other things someone A) thought shouldn't be listed by the installer or B) didn't have time to add to comps.xml. As Bill said, I probably don't even want to browse all of the python module packages, but it's better than nothing. comps may not be ideal for this but unless we go back to making the rpm group mandatory, it's the only thing we have ATM. Maybe the installer needs to have a comps.xml file that's separate from the repository comps.xml file. Maybe the hidden attribute is just what we need. Maybe we need attributes to specify who'd be interested in this (audience="programmer" audience="enduser" audience="administrator") Maybe we have to bite the bullet and come up with something better than comps. -Toshio PS. When we design something new, it should have multicategory support: <package> <name>python-gpgme</name> <category>/Language/Python</category> <category>/Security/Cryptography</category> <category>/Development/Library</category> <category>/Internet/CertificateManagement</category> </package> So I can search for the intersection of /Language/Python, /Development/Library, and /Security/Cryptography to find things closer to what I want.
Description: This is a digitally signed message part