Differences between revisions 14 and 15
Revision 14 as of 2008-02-21 14:23:39
Size: 6996
Editor: Mac
Comment:
Revision 15 as of 2008-03-21 11:06:33
Size: 7079
Comment:
Deletions are marked like this. Additions are marked like this.
Line 14: Line 14:
We have got a very basic apt backend that currently allows to search (quite slow) and refresh/update the cache. The current development takes place in the apt2 backend. It runs as a dbus controlled dameon. The list of supported features can be found in the PackageKit FAQ: http://packagekit.org/pk-faq.html

Place new comments at the bottom

Add new comments, don't edit old ones

[:/..:Parent Page] > Discussion

Sign your comments using @SIG@

The purpose of this side is to coordinate the work on the apt backend for [http://www.packagekit.org PackageKit] and on porting the exisiting applications to PackageKit, mainly update-manager and gnome-app-install. PackageKit tries to make simple and common software management tasks easier and smoother among all/most distributions.

?TableOfContents(2)

Current State

The current development takes place in the apt2 backend. It runs as a dbus controlled dameon. The list of supported features can be found in the PackageKit FAQ: http://packagekit.org/pk-faq.html

Code

Some packaging was already done:

https://code.launchpad.net/~packagekit/

Unsolved problems

Non-interactiveness of PackageKit

PackageKit only wants to support non-interactive software management tasks. But in some circumstances we need some user input. Especially if you we want to use PackageKit for update-manager we would target a huge variety of users and not only the "average home user".

@?MarioDanic@

- no question to the user - Error() if package requires user to respond - capture the stdout and pipe this to a Message() post transaction - dpkg silent mode

SebastianHeinlein

How do you want to detect this situation? Using a timeout could be very problematic, especially if you run scrollkeeper in the postinst.

?RichardHughes

I assume we can run dpkg in a --silent mode where no questions are asked. We can still parse the output text and show messages to the user but we can't ask questions like "set applet setuid" or "restart sshd?" for reasons I've detailed on the mailing list.

Sebastian Heinlein

Asking questions like the setuid one belongs to the debconf sub-issue. The problem here are not properbly written maintainer scrpits that require a stdin. How do we deal with this kind of packages? They exist so we need a strategy. At least we need a strategy how to fail.

?RichardHughes Broken packages requiring stdin shouldn't block - if this is the case then we should detect this (somehow) and error out of the transaction with PK_ERROR_ENUM_BROKEN_PACKAGE. We really can't ask the user for random stdin. We can fix broken packages, and the number of packages that are fixed will dramatically increase when they cause an error!

Debconf

A Dbus viewer for debconf could pipe the questions to the user's desktop. Some packages cannot be installed without confirming a licence which will be displayed using debconf (flash and Sun java).

@?MarioDanic@

# Dbus viewer not needed #

Procedure: Throw an error of enum type "licence-prompt-required" or something like that and the daemon should do the right thing

Notes: The messages in the transactions have to be converted to abstract types and then can be shown using pk_backend_message() which then get passed up to the session and translated into locale

SebastianHeinlein How do you want to detect a license prompt? So there will be no way to confirm it either?

?RichardHughes

We need a way to get the licence text before the download has started and the copying of files half done. I don't know the internals of dpkg, but we really can't download a legally-grey package, do most of the install and then ask for permission to download and install it. The only way to do this is to prompt before the package is downloaded or when the application is used for the first time. I've not fleshed out the details on how to interact with the daemon, as I want to make sure any interaction is compatable with all backends. The zypp backend for example can get the licence before the transaction.

I'm really not that fussed about non-free packages - maybe we can just make PackageKit work with only packages that do not require a EULA and throw an error if we try to install one that does. Installing vmware or mplab isn't the primary use case for PackageKit.

Sebastian Heinlein

AFAIK we can supress all debconf questions. But I don't want to force all the advanced users to use the terminal. Furthermore I don't see the need to maintain two graphical update tools.

Installing non-free software is THE use case of all package management software. Non-free software is the one that is not shipped by default, but most users want to have.

Richard Hughes I don't think we need to inflict the terminal on the user. We can already send nice messages to the user using Message() we just can't ask them for input. Advanced users can reconfigure packages in a debian specific helper program (I'll even ship this in PackageKit in the contrib directory if you want).

I'm also not sure on your claim that installing non-free software is the primary case for a package-manager. I don't think I have any non-free software on my laptop. But I do agree that it's an important problem to solve. After this weekend, I'll mail the list with some ideas - it would be good if you guys could join before this to discuss.

Stdin/out

Dpkg allows to read and write to the terminal in maintainer scripts. We would have to find a way to get the terminal through dbus too. If you don't make the terminal of dpkg accessible it will hang forever.

File replacement

Before replacing customizations to configuration files the user gets a prompt.

@?MarioDanic@

There will be work done NOT to overwrite configuration files by default, and show a Message() post transaction with all the details.

Message() types can be added as needed.

Note: message() is supported in recently released 0.1.4.

SebastianHeinlein:

There is no corresponding support in dpkg to collect messages and ask them at the end.

?RichardHughes

Do you have any prefix? For instance do you have "Warning: The following packages need configuring" - in which case we can parse the stderr and format a nice message than can be converted to an abstract type and show to the session. If not we can show the session user a generic message post transaction (the stdout in completeness if need be) although this sucks from a UI point of view.

Non persistent backend dameon/cache

For each operation PackageKit creates a new instance of the backend. So we have to reopen the apt cache for each simple search or sate/description query. The solution could be [http://www.enricozini.org//2007/debtags/axi-searchasyoutype.html Enricos xapian database infrastructure] . We would need a hook in libapt to update the xapian cache on cache updates automatically.

@?MarioDanic@

In discussion with Michael about this.

Missing software meta information

Because of the different package naming schemas among all distributions there is no common reference to a certain software feature.


See also

  • ?AptZip


CategoryPackageManagement