Overview of Jockey replacement; options for Kubuntu?

[Martin Pitt]

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)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/kubuntu-devel/attachments/20120531/18daed65/attachment.pgp>