http://bugzilla.suse.com/show_bug.cgi?id=1026960 http://bugzilla.suse.com/show_bug.cgi?id=1026960#c4 --- Comment #4 from Luca Beltrame <lbeltrame@kde.org> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.