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