Overview of Jockey replacement; options for Kubuntu?

[Jonathan Thomas]

Hi,

On Wed, May 30, 2012 at 9:21 AM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Jonathan Thomas [2012-05-30  8:19 -0400]:
>> > Both aptdaemon and python-aptdaemon.pkcompat are on the Kubuntu
>> > images.
>>
>> Well, yes, now that nvidia-common is forcing the dependency via
>> ubuntu-drivers-common. But they were not as of precise:
>> http://cdimage.ubuntu.com/kubuntu/precise/daily-live/20120529.1/precise-desktop-amd64.manifest
>> and such a dependency is undesirable.
>
> Ah, oops. Dropped:
>
>  https://github.com/tseliot/ubuntu-drivers-common/commit/5d0bdefd48
>
>> > It does depend on glib and python-gi, but there's little chance of
>> > avoiding glib in Kubuntu. I'm less sure about python-gi, though, that
>> > might be new.
>>
>> We'd also need a debconf frontend which would mean bringing in the
>> grk3widgets aptdaemon stuff, which is undesirable as well.
>
> Why is that? This just uses python-apt, it needs a frontend no more or
> less than anything else that uses apt?
>
>> > aptdaemon does not reimplement apt, it provides the python-apt
>> > functionality over D-BUS (similar to PackageKit, but it's a lot faster
>> > on Ubuntu).
>>
>> I didn't mean re-implement the whole thing. ;-) But already we have
>> the QApt Worker which can do this, making duplication a needless
>> waste.
>
> I think we are just talking past each other: current u-d-common
> _enables_ PackageKit/aptdaemon to ask for "what package provides a
> driver for this device". It does not require you to use it (you can
> use the native UbuntuDrivers module). I was just explaining why the
> aptdaemon stuff is there.

Ah, ok. I think it was just a misunderstanding about whether or not
aptdaemon was a requirement, due to its status as a hard dependency.
Glad to see that resolved, and no hard feelings at any rate. I was
just a bit annoyed at the (apparent at the time) unilateral
introduction of a new dependency that duplicated existing
functionality to a core package, without any discussion, so I'm sorry
if I came off as a bit terse in my replies. :)

>
>> QApt is perfectly capable of providing installation stuff over DBus,
>> so it would be better from a dependencies/ISO space standpoint.
>
> Sounds fine.
>
>> Do you know if ubuntu-drivers-common currently supports multiple
>> backends, and if it could be made to do so?
>
> u-d-common is a backend already. It currently provides these
> interfaces:
>
>  * Native UbuntuDrivers Python module (Ubuntu specific)
>  * ubuntu-drivers CLI tool (Ubuntu specific)
>  * PackageKit "WhatProvides" API (upstream friendly for GUI
>   integration)
>
> Of course we can easily add QApt integration there, too. This is a
> native Ubuntu package which is meant to bundle all the Ubuntu specific
> knowledge and backends that we need to implement easy and
> non-distro-specific GUIs and integration for driver handling.
>
> So I guess the short answer is "yes" :-)

Nice. :-)

So if I understand correctly, detect.py currently loads a backend
plugin from /usr/share/ubuntu-drivers-common/detect/ (currently the
PackageKit plugin) and uses the what_provides_modalias() and
system_driver_packages() methods in PackageKit.py for discovering
which packages need to be installed? And then if I were to write a
backend for QApt I could write a analogous QApt.py that implements
those two functions and install that to
/usr/share/ubuntu-drivers-common/detect/?

>
>> Well then an aptdaemon dependency is really unwanted in this case.
>
> Right, understood. It should be gone with the next upload, sorry about
> that.

Thanks again.

>
> Thanks,
>
> Martin
> --
> Martin Pitt                        | http://www.piware.de
> Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Jonathan