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


  1. See also

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".


- 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


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


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!

?JossMouette Packages requiring stdin are broken anyway, as they should use debconf instead for prompting.


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).


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


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.

Sebastian Heinlein:

There are some packages which break if you select the default debconf answer:

virtualbox-ose-modules (updates) sun-java flashplugin-nonfree

?JossMouette There is no need to inflict any terminal to the user. The only real need is to have a debconf frontend available, as all questions are required to go through debconf.

It is not possible to do it before downloading packages, because the questions belong in the packages themselves. The current APT behavior is to 1) download packages, 2) ask questions, 3) unpack, 4) configure. If PackageKit supports separate operations for download and install, it becomes possible to ask the questions without complication. However, this doesn’t solve the case of questions asked at step 3 (pre-upgrade checks) or 4 (file overwrites).

I really don’t understand why you don’t want of a prompting framework over DBUS. This is not the easiest to implement, but it is elegant and solves all problems listed on this page.

?RiteshRajSarraf Just wanted to put my point here. Debian's Debconf interface is one of the most powerful Package Management features Debian has. Configuring Exim, in less than a minute without touching any config file by hand, is something DebConf does very nicely. And it is not just a terminal interface. For me, on KDE, libqt4-perl provides me a nice GUI frontend to DebConf. A similar framework should be provided in PackageKit to allow DebConf interfaces. This whole non-interactiveness requirement of PackageKit is incorrect. There should be a framework in place to allow User Defined Mode (Interactive or Non-Interactive) upgrade through PackageKit.


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.

?JossMouette Not an issue; it can just be run in a dummy terminal. We just need to find a wrapper that properly supports /dev/tty as some packages are using it.

File replacement

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


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.


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


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.


There is ongoing work to make these prompts go through debconf. Another issue that can be fixed with proper debconf support.

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 Enricos xapian database infrastructure . We would need a hook in libapt to update the xapian cache on cache updates automatically.


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