State of the GnuPG ports

[Leonardo Brondani Schenkel]

On 2017-09-14 04:10, Mihai Moldovan wrote:
> If GPG 2.0 is to be replaced by 2.2, which is really a fork of 2.1, there isn't
> a lot of sense to keep it around.

Just a small clarification: 2.2 *is* 2.1, it has been "promoted", not 
forked. GPG is using odd numbers for development branches (= major new 
features) and odd for stable ones (= bug fixes and minor features only).

At some point, when a major feature has to be introduced, 2.2 will be 
forked and spawn a parallel 2.3 branch, and 2.3 at some point will be 
promoted to 2.4. I assume that once 2.4 is introduced, the 2.2 branch 
will reach EOL some time later.

> The reason gnupg2 and gnupg21 existed is that GPG 2.1 is incompatible in a few
> ways with GPG 2.0 and 1.4, which hasn't happened before. For instance, the key
> storage mechanism changed. The migration is done automatically the first time
> GPG 2.1 is executed, but any new keys will only be added to the new storage.
> Users thus cannot easily downgrade to older versions. Other changes include the
> heavy reliance on dirmngr and other tools, that are also auto-spawned in GPG 2.1.
> 
> I see that upstream wants to move on and that's probably okay. We'll have to
> follow suit.

Agreed, but since this time there's no breaking change and it's just the 
same codebase getting a version bump, it could be handled in the usual 
way — just updating the Portfile. But since the port is called "gnupg21" 
it will be confusing to keep that name. Since we have to change the name 
I seized the opportunity to discuss if we should reuse the gnupg2 name, 
introduce gnupg22, or do something else altogether.

> Another problem comes up when thinking about dependencies, though. Most programs
> explicitly depend upon a specific version of GPG and break with newer ones. One
> of such programs was gpgme, that didn't work with post-2.0 versions for some time.
> 
> Due to this, I don't know if it's a good idea to not publish ports with specific
> version numbers but only "floating-target ports". I'm probably generally opposed
> to that, since it's unclear what actual version is being pulled in by such
> pseudo ports and there is no non-breaking-guarantee, which the names might seem
> to suggest. I strongly suggest not introducing (pseudo) ports such as
> gnupg-stable, gnupg-legacy and gnupg-current.

I think both ways make sense, but have different trade-offs. I would 
like to point out that a "normal" port in MacPorts *is* "floating": they 
don't change names when versions are increased. Numbers gets introduced 
only when there are parallel versions being maintained that are not 
compatible with each other (either ABI or command-line, depending on the 
case).

In the GnuPG case, after December there will be only two maintained 
parallel incompatible versions of GnuPG: 1.x and 2.x. Nobody can predict 
the future, and nobody knows if 2.3/2.4 will introduce a storage 
incompatibility like 2.1 did. If it doesn't, in theory no extra port 
will need to be made.

Apart from the legacy 1.x branch, I think it's unlikely that there will 
be more than one development version and more than one stable version of 
GnuPG (that is supported long-term). Maybe we can plan the future with 
that in mind.

We don't actually need to choose: we could do both. We could have 
"numbered names" for the sake of dependencies, but have a "floating" 
port for the sake of the user convenience that only has a dependency to 
the corresponding release. Not saying this is necessarily a great idea, 
but it could be done.

> There's certainly a lot of work to be done. On the plus side, at least we won't
> need to patch gpg-agent to support spawning via launchd at session startup,
> since GPG 2.1+ autospawning feature should take care of that.

In the interesting of moving this forward (and I'm volunteering to 
help), and considering what has been written, I have this concrete 
proposal which tries to be pragmatic:

- 'gnupg' stays as it is
   (although personally I would really love this to became 'gnupg1')
- 'gnupg2' becomes the stable 2.x version, currently 2.2
   (although personally I would really love this to become 'gnupg')
- 'gnupg21' is marked as obsolete and redirects to 'gnupg2'
- 'gnupg2-devel' will be the development branch, next one being 2.3
   (in the same spirit as libressl-devel)
- ports should depend on path:bin/gnupg:gnupg2, allowing you to
   have either 'gnupg2' or 'gnupg2-devel' installed
   (exactly like openssl/libressl/libressl-devel)

In this way, when there are no breaking changes:
- Nothing happens until 2.3 is introduced
- When 2.3 materializes, 'gnupg2-devel' is created
- When 2.3 is promoted to 2.4, 'gnupg2' is upgraded to 2.4 and
   'gnupg2-devel' is changed to just depend on 'gnupg2'
   (since they're now equivalent)

If there are breaking changes (let's say in 2.5):
- 'gnupg2-devel' becomes 2.5 as usual
- 2.5 gets promoted to 2.6, now it depends:
   - if GnuPG is abandoning the old stable, 'gnupg2' becomes 2.6
   - if GnuPG is not abandoning the old stable (= 2 stable versions),
     'gnupg2' will also become 2.6 but then 'gnupg24' is introduced
- once more, 'gnupg2-devel' now just has a dependency on 'gnupg2'

In this proposal we still we minimize the number of port name changes, 
but still allow introducing new numbered ports if the need arises. 
'gnupg2' becomes the recommended stable version by upstream. Regarding 
allowing the installation of multiple versions, we also follow upstream 
(if they have different binaries we do, otherwise we don't).

Does it make sense? Can we agree on a concrete strategy (this or a 
proposed alternative) that we can start implementing?

Cheers,
// Leonardo.