Questions about the new comps

[Bill Nottingham]

Christoph Wickert (christoph.wickert at gmail.com) said: 
> In order to reduce the size of the F18 Xfce spin, I wanted to edit comps
> - but decided to not do so until I fully understand what is going on. I
> seem to have missed a lot since since last our discussion at Blacksburg,
> so have a lot of questions.
> 
> Here we go:
>      1. How can a package maintainer define a default, but not mandatory
>         package? Example: The Xfce SIG decided to no longer install
>         xfce4-icon-theme by default. It just takes space and we don't
>         use it. Nevertheless we want to enable users to install it
>         easily. How would we do that? Define an extra group with only
>         xfce4-icon-theme and make it an option of the Xfce environment?

That's the simplest way, yes. Under what circumstances would you expect
that a user would want to install it? If it's something where they would
only ever install it if they already know what the package name is, having
it categorized via a group seems like overkill.

>      2. Even if I cannot do it in anacoda any longer, how would I do it
>         in PackageKit? How can I make something show up in a group there
>         without making it mandatory?
>
>      3. How do the new groups translate into PackageKit groups? Will all
>         options be listed in the side pane of gpk-applications? Will
>         they dynamically change? Will all packages of a group be
>         selected?

Tackling these together:

This is sort of a two-part question - what is the available data, and what
do the tools do with it?

= The data =

Right now, nearly all 'building block' groups (part of environments, or
add-ons to those environments) are marked with:

 <uservisible>false</uservisible>

to prevent them showing up in the installer UI where they shouldn't. We
could add some code to change this, but this is how it's currently done.

We have the <environment> sections in comps that define the installation
choices, and the options to them.

We have the <category> section in comps as well, which is a little
less defined.

= The tools =

1. anaconda

anaconda uses the 'environment' sections to determine what to offer.
The left pane is populated with the list of environments. After selecting
one, the right pane is populated with:
- all add-ons for that environment
- any groups that both:
   1. are marked <uservisible>true</uservisible>
   2. have default/mandatory packages
This is for compatibility for add-on/third-party repos - if you add on, say,
a Chromium repo that has a group there, it will show up as an option for
whatever you decide to install.

anaconda ignores optional packages, unless you pass --optional in a
kickstart file.

anaconda no longer uses the <category> section.

2. apper

apper organizes groups via the <category> section. It appears to show them
whether or not the group is marked as user-visible. You can individually
select packages in these groups, but do not appear to be able to (easily)
select the group to get its default offerings. apper does not specifically
denote a package's status (mandatory/default/optional) in the UI, AFAICT.

apper does not read environments.

3. yumex

yumex organizes groups via the <category> section. It also appears to show
them whether or not the group is marked as user-visible. You can
individually select packages in these groups, or select the group to get
its default offerings. yumex does not specifically denote a package's status
(mandatory/default/optional) in the UI, AFAICT.

yumex does not read environments.

yumex has a 'categories' option that appears to have nothing to do with
comps categories, as well.

4. gnome-packagekit

gpk-application offers groups via two mechanisms:

- An uncategorized list of groups ('package collections')

This shows all groups listed in the <category> sections, in a flat list
instead of a tree. While you can select a group in this interface to get
its default offerings, you can not individually select packages from them
(as far as I can easily tell.)

- A filtered list of groups

PackageKit has its own concept of featured groups that it lists as separate
items. This list is assembled from comps groups via a mapping in
PacakgeKit's yum backend. You can individuallly select packages in groups
offered in this manner, but you can not select a group to get its default
offerings.

I did not check synaptic - people using that, frankly, are beyond my
immediate concern, but I'll answer questions on the data if they have them.

...

So, taking this into account, I think the simplest fix that ensures a
semi-coherent interface in post-install package tools while we work towards
something better would be to edit the category definitions in the comps file
so that there are categories for each installation option that lists the
add-ons for that option.

This would have the benefit of giving easy access to the options presented
in the anaconda interface in a post-install environment without having to
modify the code in those tools, at the expense of letting a user do
one-click installs of, say, the server options on top of a desktop install.
(Which you could do now anyway, with probably comical results). This would
still only help certain tool users - users of apper still couldn't select
groups, only individual packages; users of gnome-packagekit still wouldn't
see them in a heirarchical fashion.

>      4. How to define conditionals?

Those work the same way as before. What case are you trying to hit with
conditionals?

Bill