Re: Debconf and PackageKit
Hi again, now aptcc backend install/remove/update things in noninteractive mode, and following Josselin Mouette advices I'm planning to write a DBus frontend to debconf that will emit a signal when it needs a Session frontend to be attached. I created a sequence diagram to ilustrate what i'm planning and i'd like to hear from you if this sounds sensible, with this we would have PackageKit working with deb packages the same way Synaptic does just not too advanced. http://img97.imageshack.us/img97/6141/debconf.png Please give me some feedback on this so i can start coding :D Best, 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
Re: Debconf and PackageKit
I don't know if there is a better list to ask this
question but as people here know dpkg
well i'd like to know if there is some
way of telling it to use another fd as
stdin, I have done the following code
to handle answering to conffile prompts
but it works some times and other times it
doesn't... (a bit unpredictable):
This is the forked code, the parent
does a write(writeToChild[1], n\n, 2);
if (m_child_pid == 0) {
cout FORKED: installPackages(): DoInstall endl;
// close Forked stdout and the read end of the pipe
close(readFromChildFD[0]);
close(writeToChildFD[1]);
// redirect writeToChildFD to stdin
if (dup2(writeToChildFD[0], 0) != 0) {
cerr dup2 failed to stdin endl;
close(readFromChildFD[1]);
close(writeToChildFD[0]);
_exit(1);
}
close(1);
// Change the locale AND lang to not get it localized
setenv(LANG, C, 1);
setlocale(LC_ALL, C);
// Pass the write end of the pipe to the install
function
res = PM-DoInstallPostFork(readFromChildFD[1]);
// dump errors into cerr (pass it to the parent process)
_error-DumpErrors();
// HACK: try to correct the situation
if(res == pkgPackageManager::Failed) {
cerr Aptcc: A package failed to install.
Trying to recover: endl;
system(dpkg --configure -a);
}
close(readFromChildFD[1]);
close(writeToChildFD[0]);
_exit(res);
}
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
Re: Debconf and PackageKit
Daniel Nicoletti a écrit :
Hey Josselin,
De: Josselin Mouette
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.
hmm ok I'll investigate on how to use that in an apt-get based code..
Why do you use apt-get and not libapt? Especially if you’re working on a
C++ frontend…
Ok now I'm forking and using --status-fd, but i got this localized
pmstatus:k3b:0:Removendo k3b
which i can't parse, actually i'm a bit afraid if it's status are
some kind of standard, maybe i should look at the source.. :P
So what's the best solution anyway?
Clean the child env vars?
Or just use LC_ALL=C (or setenv(LC_ALL,C) or whatever
$ENV{LC_ALL}=C you need), which should be done before launching any
localized non-interactive program from which you expect some information.
--
Jean-Christophe Dubacq
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debconf and PackageKit
On Fri, 02 Oct 2009, Jean-Christophe Dubacq wrote:
Ok now I'm forking and using --status-fd, but i got this localized
pmstatus:k3b:0:Removendo k3b
which i can't parse, actually i'm a bit afraid if it's status are
some kind of standard, maybe i should look at the source.. :P
So what's the best solution anyway?
Clean the child env vars?
Or just use LC_ALL=C (or setenv(LC_ALL,C) or whatever
$ENV{LC_ALL}=C you need), which should be done before launching any
localized non-interactive program from which you expect some information.
No, he doesn't need that. For example in a French environment:
$ sudo dpkg --status-fd 1 -i ../dselect_1.15.5_i386.deb
(Lecture de la base de données... 225254 fichiers et répertoires déjà
installés.)
Préparation du remplacement de dselect 1.15.5 (en utilisant
../dselect_1.15.5_i386.deb) ...
processing: upgrade: dselect
status: dselect: half-configured
status: dselect: unpacked
status: dselect: half-installed
Dépaquetage de la mise à jour de dselect ...
status: man-db: triggers-pending
status: dselect: half-installed
status: dselect: half-installed
status: dselect: unpacked
status: dselect: unpacked
Paramétrage de dselect (1.15.5) ...
processing: configure: dselect
status: dselect: unpacked
status: dselect: unpacked
status: dselect: half-configured
status: dselect: triggers-awaited
Traitement des actions différées (« triggers ») pour « man-db »...
processing: trigproc: man-db
status: man-db: half-configured
status: dselect: installed
status: man-db: installed
The processing lines are those that seem to interest you. They do not
contain translated material in any way.
Cheers,
--
Raphaël Hertzog
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debconf and PackageKit
Hey Josselin, De: Josselin Mouette 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. hmm ok I'll investigate on how to use that in an apt-get based code.. Why do you use apt-get and not libapt? Especially if you’re working on a C++ frontend… Ok now I'm forking and using --status-fd, but i got this localized pmstatus:k3b:0:Removendo k3b which i can't parse, actually i'm a bit afraid if it's status are some kind of standard, maybe i should look at the source.. :P So what's the best solution anyway? Clean the child env vars? 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
Re: Res: Debconf and PackageKit
On Tue, 29 Sep 2009, Daniel Nicoletti wrote: I don't understand this part. Why would you have to unset LANG? What exactly do you want to avoid being localized? When apt-get install foo is installing things dpkg prints removing, unpacking, installing and those need to be mapped to enums that will be localized in PackageKit frontends. You want to use dpkg --status-fd fd to watch for this information. You should be able to tell apt to pass this option to dpkg. IIRC it's not localized in that case. Apt might also use it but dpkg supports multiple status-fd. Cheers, -- Raphaël Hertzog -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Debconf and PackageKit
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
Re: Debconf and PackageKit
On Tue, Sep 29, 2009 at 10:26:01 -0700, Daniel Nicoletti wrote: 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. I don't understand this part. Why would you have to unset LANG? What exactly do you want to avoid being localized? 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) /usr/share/doc/debian-policy/debconf_specification.html Cheers, Julien -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Debconf and PackageKit
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
Res: Debconf and PackageKit
De: Julien Cristau 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. I don't understand this part. Why would you have to unset LANG? What exactly do you want to avoid being localized? When apt-get install foo is installing things dpkg prints removing, unpacking, installing and those need to be mapped to enums that will be localized in PackageKit frontends. 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
Re: Debconf and PackageKit
De: Josselin Mouette Currently, the question will simply be ignored, the frontend being set to noninteractive when there is no TTY nor display available. The hard work imo will be if i start in an interactive mode (in the backend) but when a question needs to popup the user loged out and i need to ignore the questions.. 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. Well I think it might be easy to get accepts by Upstream if this was a separate app since no change in gnome or kde frontends would be needed to add a strictly Debian Feature, I thought of using a socket since it could be chmod to 600 for example. 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. hmm ok I'll investigate on how to use that in an apt-get based code.. 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. hmm nice to know :D 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. Yep I know they worked on aptdaemon but as the author told me it does not fit well in PackageKit as this could do. 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
Re: Debconf and PackageKit
Le mardi 29 septembre 2009 à 11:37 -0700, Daniel Nicoletti a écrit : Currently, the question will simply be ignored, the frontend being set to noninteractive when there is no TTY nor display available. The hard work imo will be if i start in an interactive mode (in the backend) but when a question needs to popup the user loged out and i need to ignore the questions.. In this case, just don’t set the questions as seen, and that’s all. They’ll be ignored or re-asked later, depending on the case. You could also switch to emulating the noninteractive frontend when that happens. 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. Well I think it might be easy to get accepts by Upstream if this was a separate app since no change in gnome or kde frontends would be needed to add a strictly Debian Feature, I thought of using a socket since it could be chmod to 600 for example. I was talking about the Gnome.pm frontend for Debconf. As for the socket idea, this is just a hack; if you’re working on a D-Bus-based frontend for APT, you need to use D-Bus for all communication. Ugh, that’s an absolutely horrible and broken solution. You should use the --status-fd dpkg option instead. hmm ok I'll investigate on how to use that in an apt-get based code.. Why do you use apt-get and not libapt? Especially if you’re working on a C++ frontend… Yep I know they worked on aptdaemon but as the author told me it does not fit well in PackageKit as this could do. Yes, OTOH it could fit as a backend to update-manager. 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
Re: Debconf and PackageKit
De: Josselin Mouette Le mardi 29 septembre 2009 à 11:37 -0700, Daniel Nicoletti a écrit : Currently, the question will simply be ignored, the frontend being set to noninteractive when there is no TTY nor display available. The hard work imo will be if i start in an interactive mode (in the backend) but when a question needs to popup the user loged out and i need to ignore the questions.. In this case, just don’t set the questions as seen, and that’s all. They’ll be ignored or re-asked later, depending on the case. You could also switch to emulating the noninteractive frontend when that happens. Good :D 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. Well I think it might be easy to get accepts by Upstream if this was a separate app since no change in gnome or kde frontends would be needed to add a strictly Debian Feature, I thought of using a socket since it could be chmod to 600 for example. I was talking about the Gnome.pm frontend for Debconf. As for the socket idea, this is just a hack; if you’re working on a D-Bus-based frontend for APT, you need to use D-Bus for all communication. Well the socket idea was one way to talk to debconf, I could setup an DBus interface to debconf so that debconf frontends could talk.. I just don't want to create another one. Ugh, that’s an absolutely horrible and broken solution. You should use the --status-fd dpkg option instead. hmm ok I'll investigate on how to use that in an apt-get based code.. Why do you use apt-get and not libapt? Especially if you’re working on a C++ frontend… I do use libapt, but I find it's docs too simple to write a whole aplication, in the code i do: result = DoInstall(file_descriptor); Probably dpkg has some env var to enable this --status-fd, or maybe this file descriptor is this ( i have to code this part.. :P ) Cheers, 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
