gpgme: relax dependency and fix unit tests depending upon gnupg

[blair (Blair Zajac)]

It appears that gpgme doesn't have a library dependency on gnupg2 as described in the Portfile:

$ otool -L /opt/local/lib/libgpgme.dylib 
/opt/local/lib/libgpgme.dylib:
	/opt/local/lib/libgpgme.11.dylib (compatibility version 26.0.0, current version 26.0.0)
	/opt/local/lib/libassuan.0.dylib (compatibility version 8.0.0, current version 8.3.0)
	/opt/local/lib/libgpg-error.0.dylib (compatibility version 20.0.0, current version 20.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)

All of these are provided by the OS or other ports.

So the patch relaxes the dependency to make gnupg2 only a build time dependency.

Also, the 'port test' works if gnupg is installed and this is fixed by patching Makefile.am instead of Makefile.in.

I can svn commit the patches.

[blair (Blair Zajac)]

And I also did a ./configure --verbose comparison between having gnupg2 installed and not and there is no difference in the output, it appears configure doesn't look for anything provided by gnupg2.

[dbevans (David B. Evans)]

I had forgotten the reasoning for why I did this, so took a few minutes off to review the code to refresh my memory.

The idea of this library is to provide a simple API that acts as a front end to gnupg. The library has a "gpg-engine" that configures itself at run time based on the version of gnupg you have installed and then communicates via the command line with whatever it finds. The current code tests for a minimum version for gnupg of 2.0.4. So there is no direct linkage between the programs and technically gnupg doesn't have be present to build gpgme but it won't work if gnupg2 is not installed for testing or at run time for normal usage. Hence the lib dependency to cover both cases.

[blair (Blair Zajac)]

Ok, thanks for looking at that.

I can add a comment and link to your note to the Portfile. Also, wouldn't depends_run be better:

     depends_run
         List of dependencies to check before destroot, install and package
         targets. Will be recorded in the registry as being required by the
         dependent port when it is installed.

[dbevans (David B. Evans)]

Yes but depends_run doesn't cover the test case which comes after build and before destroot.

[blair (Blair Zajac)]

IIRC MacPorts would build depends_run before it built the port, so in practice it would would, although by definition it could change.

[dbevans (David B. Evans)]

I haven't looked into base deeply enough to tell one way or the other, but I have observed that if a port is a run dependency and it is installed but not active, if you run the phases one by one it won't get activated until you get to destroot. Similarly, build and lib dependencies won't be checked until you get to configure.

I suppose that the truly correct approach (assuming there's not a secret depends_test keyword that I don't know about) would be to declare it as both a build AND a run time dependency but I thought that although gpgme doesn't link with with gnupg2, depends_lib would cover both cases and be simpler.

Is there a particular problematic situation that you are trying to avoid here or is this just a matter of semantics? That is, 'not a linked library' == 'not a depends_lib'.

[dbevans (David B. Evans)]

Fixed in r152331. I used your patch with an added depends_run for gnupg2 and adjusted the comment a bit. Unit tests now work again (I didn't realize I had broken them) and all is well at run time as evidenced by the correct functioning of gpgme's dependent, seahorse. Thanks for pointing out the issue and for the patch.