Bug 435627

Agree, but it was upstream who wanted to have hardcoded groups to make it easier
to do translation and add icons, not bound to the current backend.
So i had to do a mapping of yum groups (comps) to pk groups.
We have discussed it a couple of time on the pk mailing list, both group naming
and subgroups. But i have not been able to convince Richard H. yet.

Our group information already includes full translation.  And we ship icons for
all of the groups.  Seems pretty weak reasoning :(

Sure, the groups in PK are a little more abstract. They are designed to be
portable between all sorts of distros and platforms, e.g. openmoko on a mobile
phone and have an emphasis of the end user tool, rather than any arbitrary
legacy distro names.

For the translations we need to do this upstream, i.e. in gnome and KDE frontend
tools, rather than in the distro backend, and so this needs to be abstracted. I
don't mind adding more groups to the enumerated list, but I think it's fairly
important they should stay a flat list.

If we need to make it hierarchical then we can modify the API slightly, but at
the moment I just don't see the need.

Richard.
 

Richard,

There are a couple of things that pirut does nicer than PK with regards to
groups of software -

o It shows the same groups as anaconda does when you do the system installation.
 That's nice from a consistency POV.
o It lets the user install 'GNOME' or 'KDE' or 'Desktop Publishing' as a group,
and get all the required/recommended packages for that group.  Then you can
drill down and install the optional packages.

We can figure out how to improve that user experience in PK, but we should
probably take it to the mailing list.

Umm, I fail to see why the translations need to be in the frontends rather than
coming from the backend.  And similarly for what groups are available.  

Your openmoko argument actually makes this better than anything I would have
said -- what gets displayed for an "openmoko" distro is going to be vastly
different than what you want to display as being available for a general purpose
distro.

The system daemon is running in the C locale, as we can have multiple session
clients running in different locales. This means that we have to pass
non-localised messages up the stack as we do not know what application is
interested in this until it hits the session (localised) layer.

The group availability is from the GetGroups function, where the set of
enumerated group types is returned. This allows OpenMoko to support ~10 groups
and yum ~20 groups.

The best reason for not doing this in the backend is localisation policy. For
example, KDE might want the multimedia entry to read "Multimedia and Video" and
a certain icon to match all the other multimedia stuff on the KDE desktop. GNOME
may want "Sound and Video", also with thier own icon. We just can't do that
getting the localisations from the backend.

Richard.

I'll close this as WONTFIX. The other bug about not being able to install groups
is probably best in another bug, or better still, on the mailing list.