Jesse Keating <jkeating <at> redhat.com> writes:
> I won't argue that it could use improvement. I will however argue that
> the way to improve it is to have dialog with those using it and
> producing it, rather than deciding off project somewhere to just ignore
> it or apply filtering/modification to it without consulting the project
> at all.
Indeed. PackageKit should be fixed to use comps groups unmunged. Unfortunately,
PackageKit's design is fundamentally broken and thus fixing this needs API
changes. See this enum:
typedef enum {
PK_GROUP_ENUM_ACCESSIBILITY,
PK_GROUP_ENUM_ACCESSORIES,
PK_GROUP_ENUM_ADMIN_TOOLS,
PK_GROUP_ENUM_COMMUNICATION,
PK_GROUP_ENUM_DESKTOP_GNOME,
PK_GROUP_ENUM_DESKTOP_KDE,
PK_GROUP_ENUM_DESKTOP_OTHER,
PK_GROUP_ENUM_DESKTOP_XFCE,
PK_GROUP_ENUM_EDUCATION,
PK_GROUP_ENUM_FONTS,
PK_GROUP_ENUM_GAMES,
PK_GROUP_ENUM_GRAPHICS,
PK_GROUP_ENUM_INTERNET,
PK_GROUP_ENUM_LEGACY,
PK_GROUP_ENUM_LOCALIZATION,
PK_GROUP_ENUM_MAPS,
PK_GROUP_ENUM_MULTIMEDIA,
PK_GROUP_ENUM_NETWORK,
PK_GROUP_ENUM_OFFICE,
PK_GROUP_ENUM_OTHER,
PK_GROUP_ENUM_POWER_MANAGEMENT,
PK_GROUP_ENUM_PROGRAMMING,
PK_GROUP_ENUM_PUBLISHING,
PK_GROUP_ENUM_REPOS,
PK_GROUP_ENUM_SECURITY,
PK_GROUP_ENUM_SERVERS,
PK_GROUP_ENUM_SYSTEM,
PK_GROUP_ENUM_VIRTUALIZATION,
PK_GROUP_ENUM_SCIENCE,
PK_GROUP_ENUM_DOCUMENTATION,
PK_GROUP_ENUM_ELECTRONICS,
PK_GROUP_ENUM_COLLECTIONS,
PK_GROUP_ENUM_UNKNOWN
} PkGroupEnum;
This enum is all the way down in libpackagekit and the backends have no control
over its contents. This is exactly how things should NOT be done! The list of
groups should be determined by the backend (entirely, not as a bitfield of
the "which of the groups in the enum do we support" type). It should be the
backend's task to return a string and an optional icon (with a sane default,
like that "metapackage" icon) for each of the groups which are actually
present, they should not have to force their groups into a set of hardcoded
integers (and throw away everything the enum doesn't cover). The current system
is overly simplistic, inflexible and just plain dumb.
Kevin Kofler
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
