Qgpgme thoughts and issues
Closed, ResolvedPublic

Description

I have two things I'd like to raise concerning QGpgME, I hope a "nobug" ticket isn't too inappropriate for that. I searched for "qgpgme" before creating this ticket, and found nothing that seemed relevant judging from the ticket titles.

  • something went amiss during the conversion from CMake to autoconf: on Mac the QGpgmeConfig.cmake file still uses a .so shared library extension instead of the correct .dylib . This is an actual bug, but maybe already fixed in the upcoming version (like the similar issue and the lingering @libsuffix@ I encountered in the generated other gpgme .cmake files)?
  • QGpgME builds libqgpme, preserving the same name as the library that used to be built by kdepimlibs4. Most if not all generic libraries have adopted Qt's own approach of including the major version in the library name, to allow co-existence of Qt4 and Qt5 versions (e.g. libQtCore vs libQt5Core).

I have verified: a simple search-and-replace of libqgpg with libqt5gpg in the qt subdirectory suffices to build a library that can co-exist with the old Qt4 version from kdepimlibs4. Dependent software that uses CMake to find its dependencies will find the libraries under that name without any issue. Is this something that might be considered upstream, e.g. for 1.8.1, possibly as a build option? I realise this may not be something that has already come up on Linux desktops but it's likely to do so in other distribution systems; it is blocking us in MacPorts at this moment, for instance.

Details

Version
1.8.0
RJVB set Version to 1.8.0.Dec 21 2016, 11:23 AM
RJVB added a subscriber: RJVB.
RJVB added a comment.Dec 21 2016, 2:18 PM

Something else that would be nice is a possibility to build (and install) just
QGpgME, against an already installed gpgme. Would that be hard to achieve?

werner added a subscriber: werner.Dec 21 2016, 6:42 PM

Our intention is to keep the language bindings close to the core and thus
external builds of parts will create more problems than they might solve.

werner lowered the priority of this task from Normal to Wishlist.
werner assigned this task to aheinecke.
werner added a project: qt.
werner added a subscriber: aheinecke.
RJVB added a comment.Dec 21 2016, 6:50 PM

It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?

It's just a bit a pity that you have to build all of the cpp bindings again if
you just want to build the Qt bindings.

Aside from the required build system changes we wil run into problems evaluating
bug reports.

Hi,

thanks for your feedback.

Regarding library suffix in the cmake config files, sorry about that I forgot
MacOS ;-) can you please test the attached patch (macos-cmake-config-fix.diff)
that reintroduces libsuffix to distinguish between macos and linux?

QGpgME builds libqgpme, preserving the same name as the library that used to
be built by kdepimlibs4.

There was a discussion after the 1.7.0 release about this. In summary: I agree
that we should have changed the name to avoid this conflicts, but we think that
it's now too late to do that as we want to avoid additional hassle for packages.
On Linux it is only a problem with the headers (e.g. the -dev) Package as the
libraries have different soversions. On Windows it's not a problem at all as the
Application ships the library it requires.

Is this something that might be considered upstream, e.g. for 1.8.1, possibly as
a build option? I realise this may not be something that has already come up on
Linux desktops but it's likely to do so in other distribution systems; it is
blocking us in MacPorts at this moment, for instance.

How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break. E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

On Linux we have soversion and on Windows and MacOS imo usally the libraries are
shipped with the Application. But on MacPorts how does this work?

It will probably a bit more complex to maintain the buildsystem because you'd
want to exclude builds against mismatching qgpgme versions, but when done that
should be all, no?

It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version
and the GPGME version to determine which features are available. This was a huge
hassle in the old days and one of the reasons we wanted to move them closer
together so that you can rely on the API once you have a minimum required version.

See e.g.:
https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commitdiff;h=433bb8e84b2d1e50b5c5b9f7f2006b60cd7d7785
That removed lots of these feature checks.

RJVB added a comment.Jan 2 2017, 5:21 PM

Hi,

The patch works. There's 1 more issue that's been standing for a bit longer already,
and that you might want to tackle at the same time: there's no argp.h header on Mac.

On Linux it is only a problem with the headers (e.g. the -dev) Package as the

That's actually an orthogonal issue, and one that's probably easier to rectify as any
changes only become apparent when dependent software is being built.

libraries have different soversions

This is also the case on Mac, but the link library doesn't have a soversion. It's
called libqgpgme.so or libqgpgme.dylib .
There is of course the option to rename just that symlink. A bit of a hack, but one
that's relevant only during the link step, when dependent software is being rebuilt.

How does MacPorts handle this in general? IMO this is not a (q)gpgme(++)
specific problem as you will have this problem with each ABI break.

MacPorts does many things like they're done on more traditional *n*x desktops, i.e.
install libraries in a central, shared location (--prefix=/opt/local by default).
There is nothing specific it does to handle ABI breaks; they can hold up an upgrade,
or a patch is applied at some level, or a conflict is registered. Sadly there is no
central way to create -dev packages, which doesn't help here.

E.g. when we
break the ABI in QGpgME libqt5qgpgme.dylib may be incompatible and we would need
a new name.

That I don't see. The problem here isn't so much the ABI break compared to the
version shipped by kdepimlibs4, but the fact that an incompatible Qt version is used.
So no, a SOVERSION=8 upgrade doesn't impose a library name change. Cf. Poppler and
its Qt backends; they're called libpoppler-qt4 and libpoppler-qt5 .
An alternative would be to do like QCA: install the library wherever Qt's own
libraries are installed. That automatically resolves the conflict with the old
version included with kdepimlibs4, and might be less disruptive for existing
distribution packages.

It's not only the build system but the code using QGpgME / GpgME++ will be more
complex as they would need to have feature checks for both the QGpgME version

What I had in mind was a build system that refuses to do a mismatching build of QpgME
X.Y.Z against GpgME++ that's not X.Y.Z . If you don't do runtime checks there's no
guarantee anyway beyond what the dynamic linker can give, I think. Distributions can
build QpgME and only bundle the QpgME bits, and then install that against any GpgME
install. I've done that for a bit with QpgME 1.7.x against QpgME++ 1.8.0, and didn't
run into any issues.
You could probably even argue that people would be less likely to try this kind of
things if the build system gave off a big hint that they really shouldn't be doing
that. It's not like it's particularly difficult to install only QpgME, after all.

marcus updated the task description. (Show Details)Aug 10 2017, 3:08 PM
marcus updated the task description. (Show Details)
marcus closed this task as Resolved.Aug 10 2017, 3:15 PM