Opened 5 years ago

Closed 5 years ago

#52166 closed defect (fixed)

gpgme: relax dependency and fix unit tests depending upon gnupg

Reported by: blair (Blair Zajac) Owned by: dbevans (David B. Evans)
Priority: Normal Milestone:
Component: ports Version: 2.3.4
Keywords: Cc:
Port: gpgme


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.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 instead of

I can svn commit the patches.

Attachments (1)

gpgme-patch.txt (2.4 KB) - added by blair (Blair Zajac) 5 years ago.

Download all attachments as: .zip

Change History (9)

Changed 5 years ago by blair (Blair Zajac)

Attachment: gpgme-patch.txt added

comment:1 Changed 5 years ago by 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.

comment:2 Changed 5 years ago by dbevans (David B. Evans)

Status: newassigned

comment:3 Changed 5 years ago by 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.

comment:4 Changed 5 years ago by 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:

         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.

comment:5 Changed 5 years ago by dbevans (David B. Evans)

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

comment:6 Changed 5 years ago by 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.

comment:7 Changed 5 years ago by 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'.

comment:8 Changed 5 years ago by dbevans (David B. Evans)

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.