Hi Francesco! I think I can answer a few of your questions too :) (But Julian knows the APTcc backend better, so I think only he can propose a sane solution)
>> >> 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. > > Let me understand: you are trying to use packagekit to install some > packages and it hangs because it runs apt-listbugs through the > Pre-Install-Pkgs APT hook (see /etc/apt/apt.conf.d/10apt-listbugs ), > but apt-listbugs never exits since it's waiting for input. > Is this correct? Yes, I think so. (I was able to reproduce this behavior) > I am not familiar at all with packagekit (I barely recall to have heard > of it some time ago...): if I understand correctly, it's a system > activated daemon that manages package installation, upgrade, and so > forth, by using a number of possible back-ends. > One of these back-ends is based on libapt. > Do you confirm? Or am I completely off-track? Correct. By default we use the aptcc backend in Debian. > Moreover, again if I understand correctly, the packagekitd daemon gets > activated when the user uses one of the possible front-ends (some of > which are CLI tools, some others are GUI tools, and so forth). > What is not clear to me is: were you trying to use packagekit from a > command-line front-end? Or from a graphical one? This doesn't really matter, both frontends share the same code. > 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. > 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. 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. Does apt-listbugs work with Aptdaemon? I guess APTd might have the same problems. > I'm assuming that you are familiar with apt-listbugs, when used with > command-line package managers (such as aptitude, apt-get, and similar): > if you are not, please try to use aptitude (with apt-listbugs > installed) and see what happens when you try to install an RC-buggy > package. > >> >> 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. > > 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. >> 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. 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. Cheers, Matthias -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org