Questions about the new comps
 

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?
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?
4. How to define conditionals?
5. Is there more documentation than just
https://fedoraproject.org/w/index.php?title=How_to_use_and_edit_comps.xml_for_ package_groups&diff=298968&oldid=193124

Best regards,
Christoph

--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Questions about the new comps
 

Hi there,

one more question: How can one install something that is neither an
'environment' nor a minimal install install? Say I want openbox as
window manager, how would I do that?

openbox is in the group 'window-managers', but that group is not shown
in anaconda. I guess we need to creae a group for each and every window
manager and then make these groups options of either 'window-managers'
or 'basic-x-windows' (the latter is shown in anaconda).

Is this really the only way?!

Best regards,
Christoph


--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Questions about the new comps
 

Christoph Wickert (christoph.wickert@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
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Questions about the new comps
 

Christoph Wickert (christoph.wickert@gmail.com) said:
> one more question: How can one install something that is neither an
> 'environment' nor a minimal install install? Say I want openbox as
> window manager, how would I do that?
>
> openbox is in the group 'window-managers', but that group is not shown
> in anaconda. I guess we need to creae a group for each and every window
> manager and then make these groups options of either 'window-managers'
> or 'basic-x-windows' (the latter is shown in anaconda).

If you really want every window manager to be an installation option for
network installs, yes, you'd create groups and make them options of the
basic-x-windows environment. Go nuts - Jens has already done so for xmonad.
Note that in this scenario you either add the appropriate ancillary bits
(display manager, firstboot, any additional applets, what have you) either
into your window-manager option, or in another group that users would have
to select as well.

It's not really the target audience of the anaconda installation at the
moment - the idea is to provide a meaningful list of vetted and tested
installation options. (It's why they mirror the spins + a couple of server
options). Supporting an X by Y by Z matrix of window managers, display
managers, and input methods/font groups/pick-your-poison doesn't fit
into that.

Bill
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel