On 09/05/2017 08:21 PM, Rainer Müller wrote: > 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.
I guess that all makes sense. 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. 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. 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. 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. Mihai
signature.asc
Description: OpenPGP digital signature
