Le mardi 29 septembre 2009 à 10:26 -0700, Daniel Nicoletti a écrit : > Installing/Removing/Updating are the last problem of this backend > mostly because of debconf. > PackageKit works this way (if you didn't take a look at the web site): > > Backend (apt | aptcc | yum | zyppy ).... > || > || (some are completely separated process like python backends) > || > PackageKitD (an activated DBus service) > || > || (DBus interface) > || > GUI tools (gnome-packagekit, kpackagekit...) > > Some problems: > 1. Looking at the above you probably already guessed > that we have an already specified API, > like search_name, get_details.. and adding > something strickly debconf specific is not soo simple. > 2. The user is able to start an update and logout > his session, so where the DebConf dialog will be shown? > Will it hang for ever?
Currently, the question will simply be ignored, the frontend being set to noninteractive when there is no TTY nor display available. > We thought of various solutions to these problems, > and the one that might put and end to this would work like this: > - The user asks to install foo > - Backend creates a socket for debconf and (don't know how yet) > keep an eye on it. > - Backend starts installing foo... > - Backend detects that a debconf dialog is needed > - Backend check if the caller (the app that asked to install foo) is active, > then one of the two actions must be taken: > 1. If active sends a signal with the socket path and the path of an script > that > can set up a front end using this socket > 2. If not, behave like in noninteractive mode chosing default answears > OR finding a way to fail the instalation if the user is not present > (dunno which is best) This is one of the possible solutions indeed. The thing you need is actually a new frontend for Debconf, that should probably be based on D-Bus so that you can map the authentication and permissions from what comes from PackageKit. This frontend would actually consist in a middleware that forwards requests through D-Bus. The real frontend would be called by the PackageKit frontend itself. You could probably directly re-use the existing Gnome frontend to show the actual dialogs. > >>>This solution is not implemented as I don't know debconf verry well > but there is one problem that I'd like to know if there is a already a way > to deal with this: > when aptcc backend starts installing packages it's status are in a fd > which might be localized is LANG is set, so I clean LANG > and get dpkg to give strings like > removing, unpacking, that can be converted to an enum. Ugh, that’s an absolutely horrible and broken solution. You should use the --status-fd dpkg option instead. > The problem is if i unset LANG debconf is not localized too > so the user will see debconf dialog in english. This is not a problem. The frontend is responsible for extracting the templates (the protocol only tells which questions to ask), and the locale in the frontend remains that of the user. > Please be kind as I'm not familiar with this list :P > and don't know debconf and dpkg internals... > If you want download PackageKit and please > try aptcc :D Maybe you should be aware that because of the shortcomings you describe, some Ubuntu people started to work on aptdaemon as a possible PackageKit replacement, PackageKit being absolutely unsuitable for a Debian-based system at the moment. > (BTW please send me links with intesreting > info about debconf protocol, I could only find it > from a package maintainer POV) The protocol is described in debconf-devel(7). Cheers, -- .''`. Josselin Mouette : :' : `. `' “I recommend you to learn English in hope that you in `- future understand things” -- Jörg Schilling
signature.asc
Description: Ceci est une partie de message numériquement signée
