Daniel Kahn Gillmor <d...@fifthhorseman.net> writes: > Back on 2016-06-09, in Message-Id: m3r3c6hgch.fsf-u...@gnu.org on > gnupg-de...@gnupg.org, > Daiki Ueno <u...@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