How important is comps.xml to us these days? Which packages should be in comps.xml and which not?

[Thorsten Leemhuis]

On 22.09.2008 08:49, Alex Lancaster wrote:
>>>>>> "TL" == Thorsten Leemhuis  writes:
> 
> TL> On 21.09.2008 23:33, Kevin Kofler wrote:
>>> Tim Lauridsen <tim.lauridsen <at> googlemail.com> writes: [...]
>>> IMHO, a much better approach would be to: * throw out the hardcoded
>>> categories! We have that information in comps.xml, PackageKit
>>> should not try to duplicate it.  * display the comps.xml groups
>>> instead of the hardcoded categories and * add tristate checkboxes
>>> next to the groups, like in Anaconda: by default, they're in the
>>> gray state, unless you have all packages installed (checked) or
>>> none (unchecked); they can be checked or unchecked, which is
>>> equivalent to a groupinstall or groupremove, but the only way to
>>> get them into the gray state is to individually install or remove
>>> packages from the group (using the list view on the right).
> 
> TL> Strong +1 with one addition for us:
> 
> TL> * Fedora and its package maintainers need to way better job making
> TL> sure that most if not all packages are properly listed in
> TL> comps.xml -- otherwise a good portion of our packages won't show
> TL> up in any of the groups
> 
> Ideally this would be done either as a mandatory part of the original
> CVS import request (a field could be added, with an opt-out provision
> if really not appropriate for comps), or added interactively by the
> maintainer via PackageDB as I suggested in the feature request here:
> https://fedorahosted.org/packagedb/ticket/78#comment:1

Hmmmm. How much does the pkgdb know about the binary packages that get 
build from the source packages? Not much afaics, as the pkgdb mainly 
(only?) works with the (source) packages and not the ones that get build 
from it -- but in a proper comps.xml we need to list the binary 
packages, as a user might want to select the packages (rpms) foo or bar 
that both might get build from the package (srpm) foobar.

> Having to manually update the comps.xml file for multiple releases is
> painful, error-prone and probably why most package maintainers ignore
> it, especially since it is not enforced in package reviews.

+1

CU
knurd