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 <[email protected]>: > Hi, > > On Tue, May 29, 2012 at 1:23 AM, Martin Pitt <[email protected]> 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: >> >> UbuntuDrivers.detect.system_driver_packages() >> >> → 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. >> >> Thanks, >> >> Martin >> -- >> Martin Pitt | http://www.piware.de >> Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) >> >> -- >> kubuntu-devel mailing list >> [email protected] >> Modify settings or unsubscribe at: >> https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel > > -- > kubuntu-devel mailing list > [email protected] > Modify settings or unsubscribe at: > https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel -- kubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
