State of the GnuPG ports

[Jann Röder]

Seems like a reasonable compromise.
So for now there will be two non-deprecated ports: gnupg and gnupg2.
They both install the gpg executable and conflict with each other.
One question I still have is what is going to happen the the separate
gpg-agent port? Do we still want to support this for the old gnupg port?
Personally I think this is a lot of hassle for a port that probably no
one uses anyway. So I'm in favour of deprecating/removing it.

Probably a good idea to get a pull request going for this. And we can
discuss on github.

Jann


On 29/09/2017 at 11:03 Leonardo Brondani Schenkel wrote:
> 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.
>