[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: New Comps Groups

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


PS. When we design something new, it should have multicategory support:


So I can search for the intersection
of /Language/Python, /Development/Library, and /Security/Cryptography to
find things closer to what I want.

Attachment: signature.asc
Description: This is a digitally signed message part

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]