Dear Maintainer!

Please make a new binary packages with --enable-pinentry-efl for
enlightenment.

https://github.com/gpg/pinentry/commit/948105b7a34ec9a9e5479d376b7c86bafee50a01

Control: tags 909014 + moreinfo

thanks for your suggestion!  I'd put off doing this because i hadn't
heard from any debian users that this was desirable.

do you think that pinentry-efl should talk to libsecret (the way that
pinentry-gnome3 and pinentry-gtk2 do), or do you think it should be
independent of libsecret?

this isn't a standard GnuPG git reference -- please use
https://dev.gnupg.org/ links for upstream pointers!

Hope pkg-e-devel@lists.alioth.debian.org will say this is desirable.

Is it possible to subscribe it to this bug?

I even don't understand why pinentry-gnome3/gtk2 depends on libsecret
and pinentry-qt/fltk does not. Are them statically compiled to do not
make debian package dependencies? Anyway I thought pkg-e-devel should
provide a more complete answer.

over in https://bugs.debian.org/909014, sergio asked for inclusion of
GnuPG's pinentry-efl in debian.

sergio wrote::

we can certainly cc the pkg-e-devel list, as i'm doing here!

i think the underlying question is whether we expect to be pulling in
extra dependencies that will be useful or not.

libsecret talks to the "secret service", which afaik is provided only by
GNOME Keyring these days.  If a user is using GNOME, then they're likely
to use one of these pinentries.  if they're not using GNOME, then
presumably they've opted for something else, and we don't want to pull
in extra unwanted or unnecessary dependencies.

that said, this isn't a strong argument from me, just a reconstruction
of what i can recall of the decision-making process.  if anyone else has
strong feelings about this, or wants to propose a change that they think
will help users of GnuPG's pinentry, i always welcome that kind of
discussion.

all the best,

In this case I though pinentry-efl (as qt and fltk versions) should not
talk to libsecret.