#52166: gpgme: relax dependency and fix unit tests depending upon gnupg ----------------------+---------------------- Reporter: blair@… | Owner: devans@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: gpgme | ----------------------+---------------------- Comment (by blair@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/52166#comment:1> MacPorts <https://www.macports.org/> Ports system for macOS

#52166: gpgme: relax dependency and fix unit tests depending upon gnupg ----------------------+---------------------- Reporter: blair@… | Owner: devans@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: gpgme | ----------------------+---------------------- Comment (by devans@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/52166#comment:3> MacPorts <https://www.macports.org/> Ports system for macOS

#52166: gpgme: relax dependency and fix unit tests depending upon gnupg ----------------------+---------------------- Reporter: blair@… | Owner: devans@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: gpgme | ----------------------+---------------------- Comment (by devans@…): Yes but depends_run doesn't cover the test case which comes after build and before destroot. -- Ticket URL: <https://trac.macports.org/ticket/52166#comment:5> MacPorts <https://www.macports.org/> Ports system for macOS

#52166: gpgme: relax dependency and fix unit tests depending upon gnupg ----------------------+---------------------- Reporter: blair@… | Owner: devans@… Type: defect | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.4 Resolution: | Keywords: Port: gpgme | ----------------------+---------------------- Comment (by devans@…): 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'. -- Ticket URL: <https://trac.macports.org/ticket/52166#comment:7> MacPorts <https://www.macports.org/> Ports system for macOS