FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Ubuntu > Kubuntu Development

 
 
LinkBack Thread Tools
 
Old 05-30-2012, 01:58 PM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Hello Jonathan,

Jonathan Thomas [2012-05-30 9:41 -0400]:
> Glad to see that resolved, and no hard feelings at any rate.

No worries

> 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?

UbuntuDrivers.detect is fully self-contained and only needs apt. What
it does is (1) finding all modaliases in the system by parsing /sys,
(2) mapping modaliases to packages with the help of packages'
"Modalises:" headers, and a few other stuff around that.

We try hard to make most packages just declare proper "Modaliases:"
headers. However, for some special cases that's not possible.
/usr/share/ubuntu-drivers-common/detect/ has python snippets that
these special cases can provide; for example, sl-modem-daemon needs to
decide whether or not it should be installed based on checks of
/proc/asound/cards and "aplay -l". But this should remain an internal
implementation detail of system_driver_packages().

The PackageKit plugin (UbuntuDrivers.PackageKit) is just an adapter to
use the what_provides_modalias() function (which is Ubuntu specific)
in PackageKit/aptdaemon, so that WhatProvides(MODALIAS, pci:12345)
works on Ubuntu; i. e. PackageKit/aptdaemon will call
what_provides_modalias() through that plugin.

> 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/?

I don't think you need to write anything in that regard. If you
implement a GUI for KDE which displays available drivers and offers to
install them, you should either use the PackageKit WhatProvides() API
(which allows you to submit that code upstream, as it works for all
distros), or directly use the methods in UbuntuDrivers.detect (they do
not need any special privileges) to get the list of packages, and then
use QApt to get these packages installed.

Martin

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

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-30-2012, 05:29 PM
Steve Langasek
 
Default Overview of Jockey replacement; options for Kubuntu?

Hi Martin,

On Tue, May 29, 2012 at 07:23:23AM +0200, Martin Pitt wrote:
> 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 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.

I have vague recollections that the reason we never adopted packagekit
itself was because it was designed for an RPM-centric world, an in
particular did not allow packages to interact with users (i.e., debconf and
conffile prompts), and packagekit upstream was not interested in
accomodating dpkg requirements. Does using the PackageKit API introduce the
same limitations on package interaction?

Thanks,
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-30-2012, 05:37 PM
Jonathan Thomas
 
Default Overview of Jockey replacement; options for Kubuntu?

Hi Steve,

On Wed, May 30, 2012 at 1:29 PM, Steve Langasek
<steve.langasek@ubuntu.com> wrote:
> Hi Martin,
>
> On Tue, May 29, 2012 at 07:23:23AM +0200, Martin Pitt wrote:
>> 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 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.
>
> I have vague recollections that the reason we never adopted packagekit
> itself was because it was designed for an RPM-centric world, an in
> particular did not allow packages to interact with users (i.e., debconf and
> conffile prompts), and packagekit upstream was not interested in
> accomodating dpkg requirements. *Does using the PackageKit API introduce the
> same limitations on package interaction?

Thanks to work by Daniel Nicoletti PackageKit now supports debconf in
its apt worker implementation. The aptcc backend supports debconf via
the passthrough DEBIAN_FRONTEND, specifically by setting the
DEBCONF_PIPE env var to the pipe of the debconf frontend currently in
use.

So technically the PackageKit still doesn't support things like
debconf from an API POV, but the PackageKit backend can provide
debconf via passthrough as part of the install. I'd assume that the
packagekit compatibility layer that aptdaemon has runs the debconf
stuff "behind the scenes" in regards to PK calls.

>
> Thanks,
> --
> Steve Langasek * * * * * * * * * Give me a lever long enough and a Free OS
> Debian Developer * * * * * * * * * to set it on, and I can move the world.
> Ubuntu Developer * * * * * * * * * * * * * * * * * *http://www.debian.org/
> slangasek@ubuntu.com * * * * * * * * * * * * * * * * * * vorlon@debian.org
>
> --
> kubuntu-devel mailing list
> kubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
>

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-31-2012, 03:44 AM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Steve Langasek [2012-05-30 10:29 -0700]:
> I have vague recollections that the reason we never adopted packagekit
> itself was because it was designed for an RPM-centric world, an in
> particular did not allow packages to interact with users (i.e., debconf and
> conffile prompts), and packagekit upstream was not interested in
> accomodating dpkg requirements. Does using the PackageKit API introduce the
> same limitations on package interaction?

No, it doesn't. While you can use the API from the actual PackageKit,
this is not what we are going to use. Since Oneiric or so we have an
aptdaemon compatibility layer (python-aptdaemon.pkcompat) which
provides the PK API in aptdaemon.

Also, this merely provides the detection, i. e. "which driver packages
do I need here". u-d-common has no code whatsoever to actually
install/remove packages, and there is no need to: We already have
python-apt, aptdaemon, sessioninstaller, QApt, and the PackageKit
APIs for that, after all.

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 05-31-2012, 03:46 AM
Martin Pitt
 
Default Overview of Jockey replacement; options for Kubuntu?

Jonathan Thomas [2012-05-30 13:37 -0400]:
> Thanks to work by Daniel Nicoletti PackageKit now supports debconf in
> its apt worker implementation.

Right, but NB that we don't actually need this. We only need to handle
a rather small and known set of packages here (such as
bcmwl-kernel-source and nvidia-current); none of those actually use
debconf, and it should stay that way. There is no reason to ask the
user any debconf question when he already made his choices in the
"hardware drivers" GUI.

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

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 
Old 06-01-2012, 06:31 AM
Rafael Belmonte
 
Default Overview of Jockey replacement; options for Kubuntu?

Don't forget the firmwares for Wifi, DVB-TV and so..

2012/5/31 Martin Pitt <martin.pitt@ubuntu.com>:
> Jonathan Thomas [2012-05-30 13:37 -0400]:
>> Thanks to work by Daniel Nicoletti PackageKit now supports debconf in
>> its apt worker implementation.
>
>
> a rather small and known set of packages here (such as
> bcmwl-kernel-source and nvidia-current); none of those actually use

> Martin Pitt * * * * * * * * * * * *| http://www.piware.de
> Ubuntu Developer (www.ubuntu.com) *| Debian Developer *(www.debian.org)
>
> --
> kubuntu-devel mailing list
> kubuntu-devel@lists.ubuntu.com
> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel

--
kubuntu-devel mailing list
kubuntu-devel@lists.ubuntu.com
Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/kubuntu-devel
 

Thread Tools




All times are GMT. The time now is 12:54 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org