Hi, On Wed, May 30, 2012 at 9:21 AM, Martin Pitt <martin.p...@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 -- ubuntu-devel mailing list ubuntu-devel@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel