Luya Tshimbalanga wrote:
> Sharing the same point of view, I failed to understand why as open
> source the community failed to properly produce a better documentation
> for a plugin and better documentation for a cross platform front
> package manager like PackageKit while continuing to yet another
> fragmentation.
Well, the thing is, PackageKit backends tend to have various bugs and
limitations, in part due to impedance mismatch between the designs of
PackageKit and of the native package manager (e.g., PackageKit assumes that
package manager operations are non-interactive, which is not true for many
non-RPM package managers, e.g., dpkg/apt with debconf, alpm/pacman that
directly asks the user questions, etc.), in part due to general lack of
manpower (mainly because the backends can only really be maintained by
people coming from the respective distribution, but distributions typically
consider it an upstream PackageKit issue, so nobody feels responsible), and
in part because many operations are de-facto optional because different
applications need different operations (e.g., Apper was using several
operations that no other frontend was using, at least after GNOME-PackageKit
was replaced by GNOME Software, so several backends would just not implement
those operations, leaving Apper badly broken, and eventually leading to it
getting abandoned upstream as well).
Those limitations were even seen in Fedora (which has relatively good
PackageKit support), e.g., I remember the issues with Apper due to several
operations only Apper was using simply not getting implemented in the then-
latest backend rewrite (IIRC, the hif backend that replaced the yum backend
at the time). But there are other backends that are in a much worse state.
When distribution developers and users encounter these limitations, the
first suggestion that keeps coming up is always to just drop the "broken"
middleman (PackageKit) and use the native tools directly. After all, many
distributions have existing software using the native tools, which tends to
still just work, even on those distros that had neglected them (in favor of
PackageKit-based tools) for years. (Fedora is a bit of a special case in
that the native tools change so often that frontends struggle keeping up,
e.g., Yumex was eventually discontinued, was dead for years, and is now
being rewritten from scratch. Other distributions are much more conservative
in their package management tooling, so their native frontends do not break
so often. That makes it much less appealing for them to rely on an
abstraction layer such as PackageKit.)
So, the answer to why "continuing yet another fragmentation" is that the
"fragmented" tools tend to just work whereas PackageKit often does not.
E.g., many backends including the current Fedora ones have only very limited
support for package-level enumeration (e.g., no group browsing, limited or
no dependency and reverse dependency querying, etc.) because all the current
frontends (GNOME Software, KDE Plasma Discover) rely on AppStream metadata
instead (which by design does not include all packages and which also by
design does not support things such as enumerating reverse dependencies).
That in turn makes it impossible to resurrect frontends such as Apper (or
implement new ones) that would offer those features. (It is a vicious circle
because frontends cannot offer the features if the backends do not implement
them, and the backends do not implement them because no frontend uses them.)
So users naturally turn to alternatives such as Dnfdragora on Fedora,
Synaptic on Debian/Ubuntu, Pamac-GTK on Arch/Manjaro, etc. (or even the raw
native CLI tools) which offer those low-level package operations that the
PackageKit frontends and backends do not implement. But even operations that
are supposed to be supported, such as updating the system with Discover (or
GNOME Software or plasma-pk-updates or even the pkcon CLI, they all use
basically the same APIs for system updates), fail to work on some
distributions because some backends are just broken (e.g., the alpm/pacman
one). There too, users turn to native tools (in this case, pacman CLI, pamac
CLI, or pamac-gtk) as the obvious alternative.
So, to conclude, documentation is not what is missing in PackageKit. Backend
maintenance is, as is a perceived benefit (from a distribution developer's
and/or end user's point of view) over just using (typically already
existing) native tools.
Kevin Kofler
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
