can we drop -lassuan and -lgpg-error from the output of "gpgme-config --libs" ?

[Daniel Kahn Gillmor]

Hi all--

0 dkg at alice:~$ gpgme-config --libs
-L/usr/lib/x86_64-linux-gnu -lgpgme -lassuan -lgpg-error
0 dkg at alice:~$ 

But it's not clear to me why this should include libassuan or
libgpg-error.  gpgme itself may link to assuan and gpg-error, but that
doesn't mean that any project linking to libgpgme itself must also
*directly* link to libassuan and libgpg-error, if they use none of the
symbols from those libraries themselves.  The dynamic linker should
handle any necessary recursive loads.

I ask this because i'm seeing the following warnings from debian's build
infrastructure:

dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-pyme/usr/lib/python3/dist-packages/pyme/_gpgme.cpython-35m-x86_64-linux-gnu.so was not linked against libgpg-error.so.0 (it uses none of the library's symbols)
dpkg-shlibdeps: warning: package could avoid a useless dependency if debian/python3-pyme/usr/lib/python3/dist-packages/pyme/_gpgme.cpython-35m-x86_64-linux-gnu.so was not linked against libassuan.so.0 (it uses none of the library's symbols)


(and so on, for the C++ and QT bindings as well) I think this is
happening because the build process invokes "gpgme-config --libs"
explicitly and uses the resulting flags to build the project.

If we were to drop this as a requirement, then any package which tries
to directly use libassuan or libgpg-error would need to explicitly
re-add those libraries to their build process, but i think that kind of
explicit positive declaration is better than the implicit default
over-declaration that's happening here.

Likewise, it appears that libqgpgme is linking against both libgpgmepp
and against libgpgme, even though it uses no symbols from libgpgme
directly.  It'd be great to make these declarations more parsimonious.

           --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 930 bytes
Desc: not available
URL: </pipermail/attachments/20161031/85f8abee/attachment.sig>