Bug 435627 - PackageKit introduces *another* source of grouping information
PackageKit introduces *another* source of grouping information
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: PackageKit (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Robin Norwood
Fedora Extras Quality Assurance
:
Depends On:
Blocks: F9Blocker
  Show dependency treegraph
 
Reported: 2008-03-02 13:49 EST by Jeremy Katz
Modified: 2008-03-28 08:09 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-28 08:09:13 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jeremy Katz 2008-03-02 13:49:45 EST
PackageKit introduces yet another way that groupings occur beyond the two that
are already present.  This is lame and is going to be very confusing to users
and (perhaps more importantly) our contributors.
Comment 1 Tim Lauridsen 2008-03-03 06:09:33 EST
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.
Comment 2 Jeremy Katz 2008-03-03 14:14:17 EST
Our group information already includes full translation.  And we ship icons for
all of the groups.  Seems pretty weak reasoning :(
Comment 3 Richard Hughes 2008-03-03 15:48:17 EST
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.
 
Comment 4 Robin Norwood 2008-03-03 16:11:30 EST
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.
Comment 5 Robin Norwood 2008-03-03 16:12:23 EST
We can figure out how to improve that user experience in PK, but we should
probably take it to the mailing list.
Comment 6 Jeremy Katz 2008-03-03 22:34:00 EST
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.
Comment 7 Richard Hughes 2008-03-04 05:21:42 EST
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.
Comment 8 Richard Hughes 2008-03-28 08:09:13 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.