p5.24-module-signature @ 0.810.0 Incompatible with installed gnupg21

[rpgoldman]

Currently, if one tries to install this port, it fails if one has gnupg21 installed, because it requires gnupg, which conflicts with gnupg21.

Seems to work if I substitute port:gnupg21 for port:gnupg in the portfile, but perhaps there's a better fix that is agnostic between the gnupg versions.

[dbevans (David B. Evans)]

Checking Makefile.PL it appears that this module should configure and run with any of gnupg, gnupg2 or gnupg21. Will change the dependency to allow any of these and test to make sure that they all work.

[dbevans (David B. Evans)]

Not so easy. The problem is that gnupg and gnupg2 do not install any common paths and so they can be installed at the same time. I think this is true for gnupg21 and gnupg although they are marked as conflicting. Of course, gnupg2 and gnupg21 definitely do conflict and can't be installed at the same time.

As stated above, this module can potentially work with any of these. However, in the case where gnupg and gnupg2/21 are installed in parallel, due to its order of search, the module will see and select gnupg first over gnupg2/21. This doesn't seem right.

CCing the maintainers of the 3 gnupg ports. Comments please.

[Ionic (Mihai Moldovan)]

I guess you're not a big fan of variants (and I can understand that, especially related to my suggestion now), but how about two variants like gnupg_gen1 and gnupg_gen2 that dynamically switch dependencies (path:bin/gpg:gnupg vs. path:bin/gpg2:gnupg2) and also patch the source code into submission to hardcode the path to the gpg(2) binary or at least remove one branch of the auto-detection?

[dbevans (David B. Evans)]

Well, I was thinking about this and you're right, I didn't really like it but I don't see an alternative right now. As far as a default variant I would probably pick gnupg2 over gnupg. BTW, do you agree that gnupg and gnupg21 don't really conflict (as in install common paths)?

[dbevans (David B. Evans)]

In 807c08b9/macports-ports:

p5-module-signature: allow configuration with either gnupg v1 or gnupg v2

Add +gnupg1 variant to specify configuration with gnupg v1 rather than
default gnupg v2 even if both are installed. In the default case, patch
Makefile.PL to ignore any installed instance of gnupg v1.

Fixes #52795

[dbevans (David B. Evans)]

Note that in default case the port now uses a path depspec to allow any installed port that provides ${prefix}/bin/gpg2 to satisfy the dependency, i.e. gnupg2 or gnupg21. gnupg2 will be installed by default if nothing appropriate is available.

@ionic: I'll leave it to you to resolve the conflict/non-conflict between gnupg and gnupg21.

[roederja]

GPG 2.1 has a new key format that older versions cannot read. Therefore it is marked as conflicting.

[dbevans (David B. Evans)]

I understand that. That's why 2.1 is not the default and why it has warning notes that mention this. However, conflicting means that they cannot be installed at the same time because they install one or more common paths. So gnupg2 and gnupg21 conflict but they do not conflict with gnupg.

[Ionic (Mihai Moldovan)]

Well... theoretically they do not install files with the same path, but they conflict semantically. Do you want to install both so that a spurious call to gpg2 suddenly converts your keychain to the new format and deletes all your previous private keys? A user would be very confused by suddenly not seeing the keys anymore, just because something called gpg2 at some point in time (which might well be such a perl script.)

Making the ports conflict was the easiest way to counter that situation.

[dbevans (David B. Evans)]

OK. I give up. But since you're using the conflict keyword in a somewhat non-standard way, I'd suggest adding some comments to the ports explaining why you're doing it. That way you won't confuse folks like me ;-) I don't believe it has any effect on the changes I've made here.