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
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-REQUEST.TakeThisOut@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster.TakeThisOut@lists.debian.org
FAQ
Search
Profile
Private Messages
Log in
Linux