On Wed, Feb 17, 2016 at 04:51:48PM +0100, Tomas Mraz wrote: > On St, 2016-02-17 at 07:29 -0800, Brian C. Lane wrote: > > On Wed, Feb 17, 2016 at 05:52:45AM +0000, Christopher wrote: > > > I just ran into this: https://bugzilla.redhat.com/show_bug.cgi?id=1 > > > 309175 > > > It's not a huge deal (and there are several workarounds, for git > > > and for > > > other tools which default ot using 'gpg'), but it highlights the > > > mismatch > > > between the default /usr/bin/gpg running gpg1, when other tools, > > > like > > > gpg-agent, are tailored for gpg2. > > > > > > RHEL/CentOS has shipped /usr/bin/gpg with gnupg2 since at least > > > sometime in > > > RHEL6. > > > > Which was a mistake, in my opinion. > > > > > I'm not saying we shouldn't continue to ship gnupg1, but can we at > > > least > > > rename it, so gnupg package is version 2, and gnupg1 provides > > > /usr/bin/gpg1 > > > instead? This seems overdue. Is there any reason not to do this? > > > > I am opposed to this. If a tool wants/needs to > > use v2 it should be using gpg2 not gpg. gpg v1.4.x is still active > > upstream and is shipped as gpg so we shouldn't be renaming it. > > What would be your opinion for using alternatives for the /usr/bin/gpg? I'm not sure what you're asking here. We have 2 different binaries already. I don't see any reason to add more or rename the existing ones. > > The problem is that now the keystores are incompatible and it creates > big confusion to the users when they see some key in gnupg-1 and do not > see it in gnupg-2 and the other way around. Right, the problem is that gpg2 was updated to 2.1.x which changed the keystore, not that anything in gpg v1 has changed. Anything using gpg2 needs to do so explicitly. -- Brian C. Lane | Anaconda Team | IRC: bcl #anaconda | Port Orchard, WA (PST8PDT) -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
