6996
Comment:
|
7079
|
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
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.
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