On Thu 2016-11-10 04:50:08 -0800, Vincent Lefevre wrote: > No, this is wrong. In this case, the user isn't necessarily using > the graphical session.
as far as the graphical session is aware, the user is using it.
> I don't use gnome-keyring, but the dependency on pinentry comes
> from gnupg-agent, which has:
>
> Depends: pinentry-curses | pinentry, [...]
>
> However, pinentry-curses is not installed by default because
> pinentry-gnome3 is already installed via gnome.
yes, via evolution → gnome-keyring. that's why i'm recommending that
you reassign this bug to gnome-keyring
> Perhaps it should have a Recommends on pinentry-curses or
> pinentry-gtk2 to make sure that by default, pinentry-gnome3 is not the
> only one installed.
No, not pinentry-curses -- pinentry-curses is unable to talk to
gnome-keyring's secretservice. gnome-keyring should Depend: on pinentry
packages that can talk to the secretservice.
> IMHO, the correct solution would be to detect whether GNOME is used,
> and with a wrapper, select pinentry-gnome3 in this case, and
> pinentry-gtk2 otherwise when available.
how do you propose to detect whether GNOME is used? Who will maintain
such a wrapper?
> Note that pinentry-gtk2 remains superior for non-GNOME users (and
> for GNOME users who connect by SSH), because it will still be able
> to display a graphic window (which users may prefer to curses) even
> with SSH + X forwarding, contrary to pinentry-gnome3, if I understand
> correctly.
I beg to differ -- i'm a non-GNOME user and pinentry-gnome3 works quite
well with gcr on my machine.
> Otherwise, test some environment variable(s), either in pinentry-gnome3
> or in Gcr via a communication of the value with pinentry-gnome3 (but
> I think that the communication would be overkill in practice).
Please be concrete. This back-and-forth is causing me to miss out on
other productive work.
--dkg
signature.asc
Description: PGP signature
