Comment # 4 on bug 1026960 from Luca Beltrame

(In reply to Ludwig Nussel from comment #3)
> What Feature of gpgme is so desparately needed?

All of them. Upstream KDE has unmaintained its GPG bindings and moved them
directly into GPGME: this generated a new library called QGpgme which is
decoupled from the C++ GPGME bindings. 

In short, it is a hard compile time requirement for the whole KDE PIM stack. 

Additionally, if we upgrade KDE Frameworks to 5.31 (that's our intention,
barring any objections from a release POV), we will lose the ability to open
GPG-encrypted user wallets because the dependency was also bumped there.

> What incompatible changes does it bring?

There's a soversion bump, so API and ABI changes. Upstream KDE does not support
the old "gpgmepp" anymore. The "QGpgme" library is new, and not used before
GPGME 1.7.

> What if we stay with the current KDE Applications?

There have been many improvements in PIM during this development cycle,
relating to bugs, performance enhancements (I can dig the commits). All of them
aren't backportable (due to quite large changes in upstream).

Additionally, if we don't we'll be left with an unsupported library (gpgmepp)
which plugs into GPG, and so potential risks related to that.

> merge with SP3 again? If a newer gpgme is needed for KDE also the Backports
> project is affected in case KDE is meant to be synced with Leap there too.

It would make the matters considerably easier for KDE support during the life
cycle of the distro, but of course, this is just one of the deciding factors.