On Thu, 02 Jun 2011 13:14:50 +0200, Julian Andres Klode <[email protected]> wrote: > [...] >> >> 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? > No idea, but we certainly support debconf output, so it seems to be the > best option; especially as that's integrated into the desktop. Yes, and it's better if there is a package-manager which does not offer a terminal for dpkg. (As alternative maybe APTcc could transform reads from stdin to a debconf call, but this would be a really 'dirty' solution)
>> > 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. > Do I? Honestly, I don't know anything about those protocols. Oh, okay - I though you would know this. I'm involved in the PackageKit project, but never wrote much code for APTcc, so I don't know which protocols APT supports. (I thought Debconf would be the only one to support :P) >> 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). Maybe... I need to check the logs for this >> > 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... > Only administrator users are allowed, via PolicyKit. Same for PackageKit - only updating the package cache is allowed without superuser permissions. > >> [...] >> > >> 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? > Replacing the current package management stack used in default Debian > installations with GNOME (update-notifier, update-manager, aptdaemon, > sessioninstaller). Checkout GNOME-PackageKit, this already shows why PackageKit is a nice tool for end-users. (I guess professional users will still use apt directly, which is also possible since PackageKit does not block native tools) >> > >> 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? > How about checking whether the process is attached to a terminal? > >> >> > 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... :-( Yes, that's true - but I fully agree with Hughsie's law ( http://packagekit.org/pk-faq.html#hughsies-law ) and understand why Richard doesn't want package managers to ask random questions. Not sending log information directly to the pk-frontend is also not possible, because Richard says an UI displaying a terminal or log-messages window is not really user-friendly and is a sign of "giving up" by the UI. (I think it would make sense for CLI tools, but even if this gets implemented it wouldn't solve the problem) So, since PK frontends can ask Debconf questions now, I think this really is the way to go. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
