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

[Richard Hughes]

On Sun, 2008-09-21 at 21:33 +0000, Kevin Kofler wrote:
> As you'll certainly ask me why, i.e. what's wrong with the current 
> implementation, here's it: With the current UI:
> * there is no way to see what's in the collection,

You get prompted with the full list when you try and install. You can
use Get Dependencies on the collection if you want to know beforehand.

> * it is inconsistent: both the comps.xml groups and the hardcoded categories 
> are lists of packages

The hardcoded groups are not lists of packages, it's a map of comps
groups to PK groups.

> 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.

It's not. Groups are a subset of the comps groups. I've done substantial
user research, and I'm sorry to say fine grained categories _do not
work_ with real users. None of the people in
http://www.packagekit.org/pk-profiles.html could tell me what they
expected to find in base-system/system-tools or base-system/admin-tools,
or tell me the difference between them.

> * 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).

That would be a usability disaster. Do you want to try explaining how a
tristate checkbox works to any of the people on the profiles page?

Richard.