[pkg-gnupg-maint] Bug#854797: pinentry: Add pinentry-emacs package

[Daiki Ueno]

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> Back on 2016-06-09, in Message-Id: m3r3c6hgch.fsf-ueno at gnu.org on
> gnupg-devel at gnupg.org,
> Daiki Ueno <ueno at gnu.org> (cc'ed here) wrote:
>
>>>    If the loopback pinentry evolves into general purpose mechanism, I would
>>>    rather suggest to remove the Emacs specific stuff entirely.  The
>>>    rationale is:
>>> 
>>>    - The immediate motivation behind the Emacs pinentry was that the
>>>      loopback pinentry had some limitations when used as a replacement of
>>>      gpg1's passphrase prompt, e.g. [1], which was fixed a while ago.
>>> 
>>>    - Debian seems unlikely to build in the Emacs mode with Pinentry[2].
>>>      That means to add another (non-working) configuration vector and
>>>      upstream Emacs cannot rely on that feature[3].
>>> 
>>>    What do you think?  Is there really anything that can be done better
>>>    with the Emacs pinentry than with the loopback pinentry?
>>> 
>>>    Footnotes: 
>>>    [1]  https://bugs.gnupg.org/gnupg/issue1976
>>> 
>>>    [2]  https://bugs.gnupg.org/gnupg/issue2034
>>> 
>>>    [3]  http://git.savannah.gnu.org/cgit/emacs.git/tree/lisp/epg.el#n607
>
> Certainly pinentry-emacs isn't going to be distributed by default, since
> there are many more non-emacs users of gpg-agent than there are users of
> gpg-agent.

I am confused that you quote the above email while it doesn't say
anything about the pinentry-emacs subpackage, but is talking about the
INSIDE_EMACS hack, which is disabled in Debian.

By the way, we have been waiting for your response to the upstream bug
for a long time: https://bugs.gnupg.org/gnupg/issue2034

Regards,
-- 
Daiki Ueno