State of the GnuPG ports
Leonardo Brondani Schenkel
leonardo at schenkel.net
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
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:
and replace them when appropriate, redirecting to their successor
(possibly gnupg22->gnupg24, gnupg23->gnupg25); or something like
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.
More information about the macports-dev