[pkg-gnupg-maint] Bug#909014: Bug#909014: Bug#909014: pinentry-efl binary package build request

[Daniel Kahn Gillmor]

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

sergio wrote::
> On 17/09/2018 22:54, Daniel Kahn Gillmor wrote:
>
>> i hadn't heard from any debian users that this was desirable
>
> Hope pkg-e-devel at lists.alioth.debian.org will say this is desirable.
>
> Is it possible to subscribe it to this bug?

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

>> 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?
>
> 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.

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,

    --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 227 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-gnupg-maint/attachments/20180917/0105fcc0/attachment-0001.sig>