State of the GnuPG ports

[Leonardo Brondani Schenkel]

Thanks for the clarification. Comments inline.

On 2017-10-09 11:00, Ryan Schmidt wrote:
> Ports are assumed to be stable. If we want to also offer a development version, we use the -devel suffix. The stable (no suffix) and development versions install files to the same places and therefore conflict.

That seems to match the GnuPG scenario going forward, so then 'gnupg2' 
and 'gnupg2-devel' would respect the current practices. Would you agree?

(Personally I'm not a very big fan of the -devel suffix because on other 
package managers it is used for development header/libraries which in 
MacPorts are part of the main port, but that's just me. And I 100% agree 
that being consistent is way more important.)

> For other ports, we use numbered port names, e.g. python27, python36, which install files to different locations and thus do not conflict.

Mihai is the person to answer this, but I think it may not be too hard 
to make gnupg / gnupg2 installable side-by-side, so we still abide by 
the rules. In that case I stand behind the idea that the 'gpg' binary 
should be 2.x and 1.x should be 'gpg1', to be consistent with the 
direction upstream is taking and how other distros (like Debian) are 
packaging it. (Maybe the binary name could be customizable by variants 
if there's a need.)

> No ports use -stable or -current suffixes. I wouldn't want a -current suffix since it's not clear linguistically what the difference would be between "stable" and "current". And since ports are assumed to be stable, I would want to avoid adding a -stable suffix. But using just "gnupg" as the stable 2.2 port name would cause an upgrade problem, since all users who currently have the "gnupg" port installed expect that to be 1.4.
> 
> For ease of upgrading, my preference is probably that gnupg2 be updated to 2.2 and gnupg21 be replaced_by gnupg2. If desired, gnupg2-devel could be added to track the development version. If desired, gnupg1 could be introduced and gnupg could be replaced_by gnupg1. If desired, far in the future, after everybody has upgraded (i.e. more than one year after the preceding changes have been committed), gnupg2 could be copied to and replaced_by gnupg and gnupg2-devel could be copied to and replaced_by gnupg-devel.

My impression (correct me if I'm wrong) is that you're supporting my 
latest "pragmatic" suggestion since it's basically what you're 
describing here.

Well, I suppose that at this point Mihai and you should agree on the 
strategy and I have little else to add besides what I had written on the 
matter. In case you need volunteers to help doing the work (whatever 
ends up being decided), feel free to reach out to me and I'll gladly help.

// Leonardo.