Overview of Jockey replacement; options for Kubuntu?
eaglescreen at gmail.com
Tue May 29 21:28:54 UTC 2012
I think something like qapt-drivers-installer would be the best option.
Making a solution for all GNU/Linux distribution is a complex project.
2012/5/29 Jonathan Thomas <echidnaman at gmail.com>:
> On Tue, May 29, 2012 at 1:23 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
>> Hello Jonathan,
>> 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 is incorrect, Kubuntu does not use aptdaemon at all, and doing so
> would bring in a considerable amount of GTK libraries, not to mention
> yet another apt implementation. If at all I possible, I would like to
> write a QApt backend for ubuntu-drivers-common.
>> 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.
> Currently it's being dragged in by nvidia-common, so it's not exactly
> optional if you have an nvidia card...
>>> 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
>> UbuntuDrivers.detect.packages_for_modalias(apt_cache, modalias)
>> → 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.
>> I agree.
>> Martin Pitt | http://www.piware.de
>> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
>> kubuntu-devel mailing list
>> kubuntu-devel at lists.ubuntu.com
>> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
> kubuntu-devel mailing list
> kubuntu-devel at lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
More information about the kubuntu-devel