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

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

 



Tim Lauridsen <tim.lauridsen <at> googlemail.com> writes:
> The groups in comps.xml is used as meta-packages, there can be installed 
> and removed. just like yum groupinstall/groupremove.
> Ex. you can install KDE by installing the kde-desktop meta-package.
> All the meta-packages (comps groups) are located under collections.
> The categories is not used in pk-application.

I see this now in the screenshot. I'm sorry, but I think this is a really, 
really awful UI. Comps groups should be shown as categories, in the list view 
on the left, instead of the current hardcoded categories.

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,
* we still rely on the hardcoded categories which can't be controlled by the 
distribution's package maintainers and which are missing a lot of stuff from 
comps.xml, when we actually _do_ have that information and mostly throw it 
away,
* it is inconsistent: both the comps.xml groups and the hardcoded categories 
are lists of packages, yet the hardcoded categories can be listed, but not 
installed or removed as a whole, the comps.xml groups on the other hand are 
listed as packages and can be installed or removed, but there's no way to list 
their contents.

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

        Kevin Kofler

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux