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