On Wed, 01 Jun 2011 23:21:57 +0200 Matthias Klumpp wrote: > Hi Francesco!
Hi Matthias! > I think I can answer a few of your questions too :) Good. > (But Julian knows the APTcc backend better, so I think only he can propose > a sane solution) (OK, let's wait for Julian's input, then) > > >> > >> On a system with both packagekit and apt-listbugs installed, > >> apt-listbugs will block installations made by packagekit, and simply > >> hang around waiting for input it seems. [...] > > Did you see the output of apt-listbugs? > Due to PackageKit's design, backend messages aren't forwarded to the > frontend. But I can try to get the logfile of a transaction using > apt-listbugs. A log file may help in understanding what's going on, but (as I am sure you are well aware of) won't help the user to interact with apt-listbugs. In other words, a log file may help us in debugging, but is not a solution. As I said, the main purpose of apt-listbugs is to be called through the apt.conf DPkg::Pre-Install-Pkgs hook, receive info (in VERSION 2 apt hook protocol format) from apt-get (or aptitude, or similar package manager) and check whether the to-be-performed operation (package installation, package upgrade, ...) may introduce RC-bugs into the system. When this danger is detected, apt-listbugs must interact with the user, in order to ask him/her how to proceed: it has to give the user an opportunity to see which RC-bugs affect the to-be-installed/upgraded packages, to review these bugs, and to decide what to do (ignore the bug, pin the package, ...). All this must happen *before* the package manager goes on with the requested operation (installation, upgrade, ...). If the user decided to pin one or more packages, apt-listbugs will exit with a fictitious error, in order to stop the package manager; then, the user will have to restart the package manager. Given all this (which I stated explicitly just for clarity: I am sure you know or can figure out easily), I think that the design of PackageKit makes it especially hard to get apt-listbugs to play well with PackageKit. > > > Please take into account that apt-listbugs expects to receive (from the > > package manager) the apt VERSION 2 hook interface protocol output, then > > expects that the user is able to see its output and to send input to it > > (to answer questions and issue commands). > > I am suspecting that packagekit fails to meet one of the above > > requirements: if this is confirmed, then I think that packagekit should > > be fixed, so that it meets the requirements. > Reading from stdin is not allowed by PackageKit's policy, so if > apt-listbugs want to ask questions, it could do that using debconf. This is awkward: I don't even know how I could ask questions and output data through debconf from within a program written in Ruby! I searched for something (a library?) to use debconf from Ruby, but found nothing. Is there a way, as far as you know? > I don't know the version 2 protocol, so it might be necessray/possible to > fix the aptcc backend to support it. > But Julian knows more about this. It's possible that aptcc already provides the correct output, following the apt VERSION 2 hook interface protocol format (which, by the way, is not very well documented: see bug #627188, from Message #32 on). It's possible that the issue you are experiencing is only due to apt-listbugs trying to ask a question to the user (through stdout) and never receiving an answer (through stdin). > Does apt-listbugs work with Aptdaemon? I guess APTd might have the same > problems. I don't know: it's first time I hear about Aptdaemon. Normal users that install, upgrade or remove packages? Scary! I am not sure about the security implications of these possibilities: I don't think I would install Aptdaemon on any of the boxes I administer... [...] > >> This bug is release-critical, as installing apt-listbugs renders > >> packagekit unusable (you can't install or upgrade anymore). Just like > >> 606025, this blocks any adoption of PackageKit as default. Adoption of PackageKit as default for what? Do you mean that the goal is having it as a dependency of some package or meta-package? Which (meta-)package? > > > > I may add a Conflicts, or Breaks, or something like that, to > > apt-listbugs to state that apt-listbugs does not work well with > > packagekit. > > But maybe it should be packagekit to declare such incompatibility? > If this can't be resolved, PK would need to conflict with apt-listbugs. Which, obviously, is reasonable, but does not sound good. > > >> Proposed solution: apt-listbugs should not wait for input when started > >> under PackageKit. > > > > I am not convinced: apt-listbugs would be utterly useless, if the user > > weren't able to choose what to do, whenever RC-bugs are found to affect > > a to-be-installed or to-be-upgraded package! > > Moreover, I don't think apt-listbugs is able to know which package > > manager has launched it... > It might be possible to detect whether packagekitd executes apt-listbugs > or if it is executed directly. How can I distinguish whether apt-listbugs has been called by apt-get, (or aptitude, cupt, or similar), or else by packagekit? > Then apt-listbugs would still work for users running upgrades via > command-line. > But the best way really is to fix apt-listbugs or the APTcc backend, so PK > and apt-listbugs can work together. I would love to make this possible, but the design of PackageKit seems to make it especially difficult... :-( -- http://www.inventati.org/frx/frx-gpg-key-transition-2010.txt New GnuPG key, see the transition document! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpz1H66LMg35.pgp
Description: PGP signature
