gnupg12, gnupg users, please reply.

[Mihai Moldovan]

* 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4265 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.macosforge.org/pipermail/macports-dev/attachments/20140709/c35c7f08/attachment.p7s>