PackageKit
|
⇤ ← Revision 1 as of 2007-10-17 13:34:54
Size: 1695
Comment: initial draft
|
Size: 2862
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 20: | Line 20: |
| PackageKit is a interessting project that promisses a unified way of package manipulation tools accross all distros. | PackageKit is a very interessting project that promisses a unified way of package manipulation tools accross all distros. |
| Line 28: | Line 28: |
| Investigate what needs to be done to port all (or some) of our packaging tools to PackageKit. What are the benefits/drawbacks? Should we abandon our tools and switch to the gnome package kit implementations? | The next ubuntu release will be a LTS so we take a cautious approach to the adoption of PackageKit. We will package Packagekit and make it available in our repository. Applications like gnome-app-install and update-manager will be prepared for switchting by abstracting the backend (currently python-apt) so that its easy to flip a switch and make them use packagekit. We need to invetigate and discuss with upstream what to do about interaction during a package install. Currently during a package install interaction may be required for: * conffile prompts * debconf questions * terminal interaction The debconf prompts can be made non-interactive easily with DEBIAN_FRONTEND=noninteractive. For the configuration we could add --force-confnew or --force-confold to the dpkg commandline (also this would conflicts with the expectations that traditional users have). The terminal interaction is the hardest problem. It is currently not forbidden by debian policy to ask terminal questions and some core applications like libc6 do that in situations. This is a problem for a applicaiton like update-manager where there is no control over the packages that are going to be installed. This problem needs to be discussed with upstream. A possible solution is to provide a extenstion to the current protocol that is debian/dpkg specific. Another is to make terminal interaction deprecated in debian policy and get packages to follow that. We need to review the current status of the apt/dpkg backend and help improving it. |
| Line 32: | Line 61: |
| TBD | Some packaging work is done by Sebastian Heinlein in https://code.edge.launchpad.net/packagekit/. A packagekit team is created. |
| Line 36: | Line 67: |
| * There is currently no way to do user interaction during a install, this is a problem for us because of: * conffile prompts * debconf questions * maintainer script prompts |
Interaction during install is a problem for us that needs to be solved first. |
| Line 41: | Line 70: |
| == BoF agenda and discussion == Use this section to take notes during the BoF; if you keep it in the approved spec, use it for summarising what was discussed and note any options that were rejected. |
Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.
Launchpad Entry: package-kit
Packages affected: apt, synaptic, update-manager, gnome-app-install, adept, gdebi
Summary
PackageKit is a new cross-distro framework that abstracts from the actual underlaying package system. Backends are available for systems like yum, apt, connary (and more).
This spec investigates how it affects us and if/how we can make use of it.
Release Note
TBD
Rationale
PackageKit is a very interessting project that promisses a unified way of package manipulation tools accross all distros.
Use Cases
Bob comes from a different linux distro that uses PackageKit and switches to Ubuntu. He feels at home immediately when he finds that ubuntu offers PackageKit too.
Design
The next ubuntu release will be a LTS so we take a cautious approach to the adoption of PackageKit. We will package Packagekit and make it available in our repository. Applications like gnome-app-install and update-manager will be prepared for switchting by abstracting the backend (currently python-apt) so that its easy to flip a switch and make them use packagekit.
We need to invetigate and discuss with upstream what to do about interaction during a package install. Currently during a package install interaction may be required for:
- conffile prompts
- debconf questions
- terminal interaction
The debconf prompts can be made non-interactive easily with DEBIAN_FRONTEND=noninteractive. For the configuration we could add --force-confnew or --force-confold to the dpkg commandline (also this would conflicts with the expectations that traditional users have). The terminal interaction is the hardest problem. It is currently not forbidden by debian policy to ask terminal questions and some core applications like libc6 do that in situations. This is a problem for a applicaiton like update-manager where there is no control over the packages that are going to be installed. This problem needs to be discussed with upstream. A possible solution is to provide a extenstion to the current protocol that is debian/dpkg specific. Another is to make terminal interaction deprecated in debian policy and get packages to follow that.
We need to review the current status of the apt/dpkg backend and help improving it.
Implementation
Some packaging work is done by Sebastian Heinlein in https://code.edge.launchpad.net/packagekit/. A packagekit team is created.
Outstanding Issues
Interaction during install is a problem for us that needs to be solved first.
DesktopTeam/Specs/PackageKit (last edited 2008-12-28 10:31:49 by 124-170-206-72)