Hi, following pusling advice I'd like to explain the issues involved in this subject and a proposed solution. If you don't know anything about PackageKit it might be interesting to look at www.packagekit.org.
I started to contribute to PackageKit willing to have it working on the system I use (Debian of course), but after I "finished" KPackageKit Debian support was almost at the same stage an apt backend written in python that didn't support lots of apt features like localizing, media changing, and installing packages that need removal of others... As I'm not a python fan i decided to do a new apt backend written in cpp (which does a difference in speed), apcc was created and most of the issues the py version had aptcc does not have I added media change support to Pk, descriptions of packages are now localized, and recently i added a new method called simulate that allowed me to emit packages to be removed in an install transaction. So now it works very close to what apt-get does. 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? 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 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. The problem is if i unset LANG debconf is not localized too so the user will see debconf dialog in english. My solution would be to have an extra env var like DEBCONF_LANG or DPKG_LANG (sorry if they already exist but i could not find it) This way dpkg can run not localized and debconf will have the right locale. 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 (BTW please send me links with intesreting info about debconf protocol, I could only find it from a package maintainer POV) Thanks, Daniel. ____________________________________________________________________________________ Veja quais são os assuntos do momento no Yahoo! +Buscados http://br.maisbuscados.yahoo.com -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org