[pkg-gnupg-maint] Bug#840642: gpgme binding cleanup

[Andre Heinecke]

On Wednesday 12 October 2016 20:34:25 Daniel Kahn Gillmor wrote:
> However, we also have several remaining copies of GPGME bindings in
> debian, and it would be good to reduce their number.  This will save the
> sanity of our users; will provide better focus for upstream developers;
> and will be easier for us to maintain going forward.
> 
> In debian, we have:
> 
>  * src:kdepimlibs, which builds several binary packages, including:
>    - libgpgme++2v5
>    - libqgpgme1
> 
>    We should be able to drop these two binary packages from the build of
>    src:kdepimlibs; packages linking against these tools should be able
>    to rebuild against libgpgmepp6 and libqgpgme6.  This means that any
>    build-dependencies should probably move to libgpgmepp-dev instead of
>    kdepimlibs5-dev

For libqgpgme rebuilding kdepimlibs depending packages wont't work because 
kdepimlibs qgpgme was Qt4 and libqgpgme from the gpgme package is Qt5. You 
can't link Qt4 and Qt5 together.

For gpgmepp It would require changing how the library is found. And depending 
on the used API this will not work as gpgmepp from the gpgme package slightly 
broke API to use C++11 memory instead of Boost (so that it is now plain c++ 
without external dependencies) and some deprecated API was removed.

But that affected mainly esoteric API regarding Assuan interaction.
Additionally you now need C++11 which kdepimlibs did not.
 
>  * src:gpgmepp, which builds several binary packages, including
>    - libkf5gpgmepp5
>    - libkf5qgpgme5
> 
>    We should be able to drop this entire source package from the
>    archive.  Any build dependencies should probably move to
>    libgpgmepp-dev from libkf5gpgmepp-dev.

Yes. But as the libraries are coinstallable keeping around the current Version 
probably won't hurt. As said above there was a slight API break.

> Turns up the following packages that might need to be rebuilt:
> 
>   kaddressbook
>   kde-runtime
>   kget
>   kmymoney
>   libkf5libkleo5
>   libkf5wallet-bin
>   libkleo4
>   libkwalletbackend5-5
>   libmessagecomposer4
>   libmessageviewer4

This list looks incomplete to me (probably implicity dependencies?). At least 
Kleopatra is missing or are you not shipping a kde4 based kleopatra anymore? 
(In that case I wonder why kaddressbook is in there)

> One thing i note is that we have libkleo4 and libkleo5.  I don't know
> how tightly-bound kde4 is with qt4, 

Complete tightness. :-) You can't link qt4 and 5 together.

> but it maybe we want a separate
> binary package of libqgpgme that is built against qt4 instead of qt5.
> I can look into providing that as a separate build in gpgme if that
> would be useful.

In kdepimlibs (qt4) qgpgme was very small, just two (very useful) classes, 
maybe we could provide the kdepimlibs qgpgme offererd when built agains Qt4 but 
I doubt the usefullness.

Completly converting qgpgme (from gpgme, which included a lot of API from 
libkleo) to Qt4 is not something I'd like to see as it uses nice features of 
Qt5.

> Let me know what you think the next steps should be in proceeding with
> this cleanup.  (or if you think we should abandon the whole thing!)

I don't think you can get rid of the packages from kdepimlibs. So the cleanup 
would be only phasing out libkf5gpgmepp5 and libkf5qgpgme5 which should happen 
of course.

-- 
Andre Heinecke |  ++49-541-335083-262  | http://www.intevation.de/
Intevation GmbH, Neuer Graben 17, 49074 Osnabrück | AG Osnabrück, HR B 18998
Geschäftsführer: Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 630 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.alioth.debian.org/pipermail/pkg-gnupg-maint/attachments/20161013/91fc028c/attachment-0001.sig>