Red Hat Bugzilla – Full Text Bug Listing
|Summary:||PackageKit introduces *another* source of grouping information|
|Product:||[Fedora] Fedora||Reporter:||Jeremy Katz <katzj>|
|Component:||PackageKit||Assignee:||Robin Norwood <robin.norwood>|
|Status:||CLOSED WONTFIX||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2008-03-28 08:09:13 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
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.