Overview of Jockey replacement; options for Kubuntu?
martin.pitt at ubuntu.com
Tue May 29 05:23:23 UTC 2012
Jonathan Thomas [2012-05-25 9:09 -0400]:
> I think that we'd rather not use PackageKit (for Kubuntu at least).
Please note that it just provides a PackageKit API. We don't use the
actual PackageKit in Ubuntu as well, but the python-aptdaemon.pkcompat
wrapper. Kubuntu does the same.
This provides an upstream friendly API, so that our GUIs for driver
detection do not have to stay distro specific for all times. However,
you don't have to use it, of course.
> We already have python-apt and QApt as part of the default Kubuntu
> install, so having a third apt worker implementation would be
> undesirable. Could the new jockey communicate with a "what
> provides-helper" written with libqapt that uses DBus for
> communication, and use the qaptworker for running installs if I were
> to implement such a helper?
ubuntu-drivers-common also provides a simple custom API:
→ give me all driver packages for this system
→ give me the driver package(s) for this piece of hardware
which you can use and wrap however you like.
> > * Kubuntu implements a similar (or their own) design using the
> > ubuntu-drivers-common API in the KDE control center as an embedded
> > tab. Then we can also drop jockey-kde.
> ... then I think it would be beneficial to write a KConfig Module so
> that it could be integrated as a sub-page of the "Display and Monitor"
> page in KDE's System Settings. I attempted to write a Jockey frontend
> for this a few years back, but was foiled due to the multithreading in
> jockey not playing nice with the KDE plugin apis.
That could work better now. The "basic" API (system_driver_packages()
and packages_for_modalias()) does not use anything fancy like threads,
D-BUS, async, etc, just plain python-apt.
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
More information about the kubuntu-devel