* On 08.07.2014 10:40 pm, David Evans wrote: > My preference is to try and be guided by the spirit of the upstream > developers and how they configure their project.
Yes, that sounds reasonable. > So, I vote to leave gcr depending on gnupg for now, since it doesn't > use the extra capabilities of gnupg2, the configure file only falls > back to gnupg2 if gnupg is not installed and there is no configure > option to specify which one you want. Depending on gnupg, therefore, > is the only way to ensure deterministic configuration in the case > where both versions of gnupg are installed (without a patch). Oh, wow. They should provide a configure flag to enable/disable specific versions of GPG. I took a look at configure.ac and can (sadly) confirm your findings. > In the case of gpgme 1.5.0, it works the other way round. The > package only falls back to gnupg if gnupg2 is not detected and again > there is no way to specify which one you want. So depending on > gnupg2 is the only way in this case to ensure you have a > deterministic build. By the way, this package now does this version > check logic at run time, not configure time, so changing its > behavior is more challenging. This is even worse! There's no way to know which package is being used beforehand. > I've gone ahead and updated gpgme to 1.5.0 using gnupg2 in r121819. > I've kept gnupg2 as a lib dependency rather than a run dependency > since it's needed for confidence checks that are run as part of the > build and test phases. Yep, sounds sane too. > I think that applying similar logic to the rest of the gnupg > dependents would yield a reasonable solution as to which version to > use. If the package allows one to specify explicitly which version > to use, I would go with gnupg2. Otherwise, I would use whichever > version it favors and will provide a deterministic configuration. OK, I'll keep that in mind. Personally, I'd always prefer GPG 2 if possible/selectable. :) Mihai
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
