installing gnupg 2.2 as "gpg", vs coexistence with gpg 1.4

[Greg Troxel]

In pkgsrc (a portable multi-arch multi-os packaging system), we
currently have gnupg 2.2.0 (yes, needs update) and 1.4.22.  To allow
both to be installed at once, long ago when 1.4 was normal and 2.2 was
new, we used the"--enable-gpg-is-gpg2" configure flag, or the default
without that.  This caused users to tend to use gpg 1.4 for OpenPGP, and
gpgsm from 2.0 for S/MIME, and the 2.0 agent.  Other than perhaps using
older code, all was ok.

Now, with the incompatible agent changes, gpg 1.4 is unusable (if one
considers the agent mandatory).  So that leads to dropping
--enable-gpg-is-gpg2 to make gnupg 2.2 install as gpg, which leads to
either just not having 1.4, or letting it conflict (only one can be
installed), or to hacking in a --enable-gpg-is-gpg1 option which doesn't
seem to exist.

It seems that with 2.2, --enable-gpg-is-gpg1 is no longer default in
configure.ac, but README is lagging.

So, I wonder what the collective wisdom is, among:

  1) Nobody should use 1.4 for anything.  Just use 2.2.  Don't even have a
  1.4 package.

  2) There are reasons to use 1.4, but it's odd.  Don't bother to
  accomodate people, and it's ok if the 1.4 and 2.2 packages can't be
  installed at once.

  3) 1.4 is normal enough that packaging systems should allow installing
  both at the same time, but typing "gpg" should get gpg 2.2.x

  4) something else


Curentl, I lean to 2 and if it turns out 3 is true maybe move to 3.

Thanks,
Greg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 162 bytes
Desc: not available
URL: </pipermail/attachments/20170928/c76856d8/attachment.sig>