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)
signature.asc
Description: Digital signature
-- ubuntu-devel mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
