clone 628835 -1 reassign -1 apt-listbugs retitle -1 apt-listbugs: please work well with packagekit severity -1 wishlist tags -1 + moreinfo reassign 628835 packagekit retitle 628835 packagekit: should conflict with apt-listbugs, until it works well with it thanks
On Thu, 02 Jun 2011 13:50:59 +0200 Matthias Klumpp wrote:
> On Thu, 02 Jun 2011 13:14:50 +0200, Julian Andres Klode <j...@debian.org>
> 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.
OK, this makes a wishlist bug for apt-listbugs: you are asking that
apt-listbugs is modified so that it works well with packagekit
(something that apt-listbugs was not designed to do, and has never done
before).
It seems that I'll have to implement a DebconfFrontend for all the
interaction with the user (and make apt-listbugs use it by default,
instead on ConsoleFrontend).
Open questions:
(A) how can a program written in Ruby use debconf to interact with the
user?
(B) will a DebconfFrontend be (necessary and) enough to make
apt-listbugs work well with packagekit?
Suggestions and documentation for (A) would be appreciated.
Help in investigating (B) is especially needed: that log file we were
talking about would be useful to understand whether the problem is
really that apt-listbugs wants to use stdout and stdin, but cannot
(when started by packagekit).
[...]
> >> > 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)
Please perform the following test.
Create the following configuration file:
$ cat /etc/apt/apt.conf.d/09hookinfo
DPkg::Pre-Install-Pkgs {"/bin/cat - > /tmp/hookinfo.txt";};
DPkg::Tools::Options::/bin/cat "";
DPkg::Tools::Options::/bin/cat::Version "2";
and try to install or upgrade some packages with packagekit.
You should get what is sent through the hook interface in a nice file
named /tmp/hookinfo.txt
This file should have the format documented in
http://bugs.debian.org/627188#68
Please attach this file in your reply (to bug -1), so that I can take a
look at it.
>
> >> 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
As I said above, this check would be very helpful to shed some light on
the open question (B).
Please tell me the outcome (in a reply to bug -1).
>
> >> > 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 is better, but... what do you mean by "administrator users"?
The ones that belong to some group? Which group?
>
> >
> >> [...]
> >> > >> 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).
Default Debian installations with GNOME means that it would be a
dependency (or recommendation) of meta-package gnome, right?
> 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)
It's a relief that packagekit does not prevent users from running, say,
aptitude from the command line!
It would be really bad for Debian, if it did.
>
> >> > >> 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?
Yes, maybe, but after that?
What should apt-listbugs do, if it detects that it is not attached to a
terminal? It should be quiet and assume the answers to all questions.
Wait! But apt-listbugs already does that, if I recall correctly.
See /usr/share/apt-listbugs/apt-listbugs/logic.rb:172
if ! $stdout.isatty
@quiet = true
@yes = false if @yes.nil?
end
This means that, if packagekit really causes apt-listbugs' stdout to
not be a tty, apt-listbugs should exit with an error and stop any
installation/upgrade that may introduce RC-bugs into the system.
If, in your experience, apt-listbugs (started by packagekit) hangs and
waits for input, then, maybe, the issue is not I/O through
stdin/stdout...
Maybe the problem is really that the aptcc back-end fails to provide
the VERSION 2 apt hook interface protocol output...
If this is confirmed, then I think the aptcc back-end should support
the VERSION 2 apt hook interface protocol output.
In the meanwhile (until aptcc is fixed to provide the correct hook
output, and until apt-listbugs begins to work well with packagekit),
I think packagekit should conflict with apt-listbugs.
--
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
pgpnPswiGPTQs.pgp
Description: PGP signature
