On Thu, 2011-06-02 at 12:36 +0200, Francesco Poli wrote:
> On Wed, 01 Jun 2011 23:21:57 +0200 Matthias Klumpp wrote:
> > > 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?
No idea, but we certainly support debconf output, so it seems to be the
best option; especially as that's integrated into the desktop.

> 
> > 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.

> 
> 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...
Only administrator users are allowed, via PolicyKit.


> [...]
> > >> 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).

> > 
> > >> 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...   :-(


-- 
Julian Andres Klode  - Debian Developer, Ubuntu Member

See http://wiki.debian.org/JulianAndresKlode and http://jak-linux.org/.





-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Reply via email to