State of the GnuPG ports

Leonardo Brondani Schenkel leonardo at
Tue Sep 5 19:05:17 UTC 2017

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:

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
as an interim solution for the issue
until there's a plan on how to move forward with the GnuPG ports.

// Leonardo.

More information about the macports-dev mailing list