State of the GnuPG ports

[Jann Röder]

I also agree with what you wrote. The three ports

- gnupg-legacy (possibly call this gnupg14 - since this is unlikely to
change)
- gnupg-stable
- gnupg-current

should all conflict with each other.

I'm in favour of keeping version numbers out of port names because if
upstream iterate quickly you'll end up with lots of ports.

I think all gnupg ports should install an executable called gpg (with a
symlink to gpg2 - if this is really a problem).

The gnupg port should be an alias of gnupg-stable. I suppose
dependencies should just depend on the gpg executable rather than a
specific port (and list gnupg as the port that installs it).

This will also solve the problem in your port since the
dependency on the gpg executable can be satisfied by all three ports.

Jann

On 05/09/2017 at 20:05 Leonardo Brondani Schenkel wrote:
> On 2017-09-05 20:21, Rainer Müller wrote:
>> On 2017-09-04 23:17, Leonardo Brondani Schenkel wrote:
>>> My suggestion for how MacPorts should handle this, moving forward, and
>>> to reduce disruption:
>>>
>>> - port "gnupg" stays the same
>>> - port "gnupg2" becames 2.2.x and installs as $prefix/bin/gpg, and a
>>> symlink in $prefix/bin/gpg2 for backwards compatibility and to satisfy
>>> existing ports
>>> - port "gnupg21" is made obsolete with a note to install "gnupg2"
>>>
>>> Any thoughts?
>>
>> Totally in favor. I have been using gnupg21 for a while and had to keep
>> local modifications for some dependencies.
>>
>> But let us hear how Mihai as the current maintainer of the gnupg* ports
>> thinks about that.
> 
> If we want to plan a little bit further, I was looking at the gnupg
> mailing list:
> https://lists.gnupg.org/pipermail/gnupg-devel/2017-August/033046.html
> 
> And it seems that the upstream plan is to have 3 branches:
> - a "legacy" branch (1.4.x)
> - a "stable/LTS" branch, no new features (currently 2.2.x)
> - a "current" branch, new features (eventually 2.3.x)
> 
> Maybe we want to keep that in mind and come up with the same
> organization in terms of ports, in order to avoid some of the issues
> that arose with gnupg/gnupg2/gnupg21?
> 
> We could name use the actual version numbers:
> - gnupg14
> - gnupg22
> - gnupg23
> and replace them when appropriate, redirecting to their successor
> (possibly gnupg22->gnupg24, gnupg23->gnupg25); or something like
> - gnupg-legacy
> - gnupg-stable
> - gnupg-current
> so the names of the ports stay stable.
> 
> Maybe "gnupg" could become just an "empty" port with a dependency on the
> recommended version (either the stable or current, could even be
> configured by a variant).
> 
> I didn't think too much about this, I'm just seizing this opportunity to
> throw some ideas out there.
> 
> P.S.: I would appreciate if I could get feedback on
> https://github.com/macports/macports-ports/pull/743
> as an interim solution for the issue
> https://trac.macports.org/ticket/54749
> until there's a plan on how to move forward with the GnuPG ports.
> 
> // Leonardo.
>