> > 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
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.
> QApt is perfectly capable of providing installation stuff over DBus,
> so it would be better from a dependencies/ISO space standpoint.
> 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
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" :-)
> Well then an aptdaemon dependency is really unwanted in this case.
Right, understood. It should be gone with the next upload, sorry about
Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)