State of the GnuPG ports

[Mihai Moldovan]

On 10/09/2017 11:00 AM, Ryan Schmidt wrote:
> 
> On Oct 9, 2017, at 03:45, Leonardo Brondani Schenkel wrote:
>> On 2017-10-09 10:25, Ryan Schmidt wrote:
>>> On Oct 8, 2017, at 18:46, Mihai Moldovan wrote:
>>>> The strategy will be gnupg-{legacy,stable,current} like you suggested.
>>> Do we really want to do that? We don't do that for other ports.

Yes, pretty much. It may sound weird to you at first, because you're not used to
this naming scheme, but it makes sense in this case.

> 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".

I guess gnupg-current should be made gnupg-devel instead, though, to be in line
with the other ports we already have.

gnupg-legacy is a good name for what this port is. It's a legacy, yet
(currently) still maintained release, that can be installed by users who need
it. It will work for basic needs, but naturally lack modern features. The
tradeoff is justified by it leaner line of dependencies. It does't need an agent
to work and hence no pinentry. While we do have pinentry-mac, this port
typically only works on newer OS X releases. Unsupported OS X releases are
forced to use the pinentry port, which pulls in either Qt{4,5} or GTK+ as
(huge!) dependencies.

This said, gnupg-legacy shouldn't ever be installed by default. Only if really
requested.

gnupg-stable might be a name that is different from all the others, but better
than "gnupg2". If we offer users a choice between "gnupg-legacy" and
"gnupg-stable", it's much more clear what this choice entails and what to
choose. "gnupg1" vs. "gnupg2" isn't that clear, without knowing GnuPG
maintenance internals up-front. For usability, I really like "gnupg-stable".

Does that make sense to you as well? I realize it might take some time to get
acquainted with that scheme, but it's really logical in itself and I like it.


> 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. 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.

We've messed up the situation in the past by having a "gnupg" port, that really
is the 1.4 legacy/"classic" release. This should have been renamed a long time
ago, but alas, that happened and it's probably my fault.

Going forwards, I want to keep the gnupg port as an obsolete stub port. I will
not use the obsolete PortGroup, but implement this myself and error out with a
message that recommends users to install gnupg-stable in pre-fetch. At the same
time, it will be replaced_by gnupg-legacy, so that users who just upgrade from
gnupg will be kept on the same release, but users who want to install a gnupg
port freshly get a message that tells them what to look for (i.e., the modern,
stable version.)

I actually told Jan something different yesterday (replaced_by gnupg-legacy if
gnupg is already installed, otherwise replaced_by gnupg-stable), but that
doesn't work. I looked up the base code and noticed that replaced_by is only
taken into account for upgrades. A useful error message in the pre-fetch block
should be fine, though.

The reason for doing it like this is to try to please all users. Users, who
already are on gnupg for a specific reason will not be forced to upgrade if they
don't want to (but can still do so manually later at their convenience), while
users that try to install the obsolete "gnupg" port will be handholded in
choosing the right port to look for.

Otherwise, I can already sense new bug reports from people that want to keep
their beautiful 1.4 setup, but we broke it.


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

Which is yet another reason for not using numbered ports - most of these ports
are mutually exclusive. At least gnupg-stable and gnupg-devel.


> There are four ports which have -legacy versions: darwinbuild, libusb, 
> octave, pdfgrep. I consider this naming style to be unusual and don't know 
> why it was chosen in these cases.

Probably to help with tools that expect older releases and break with new ones.
The question, really, is whether these legacy versions are still maintained
upstream. If not, they should be phased out, otherwise I guess it's fine to have
them for now.



Mihai

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 927 bytes
Desc: OpenPGP digital signature
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20171009/6002b7f0/attachment.sig>