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.
