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 created on my machine a symlink /usr/bin/gpg to gpg2 to solve these
kind of issues.
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.
No matter how far down the wrong road you've gone, turn back.
(You'll never know whether the road is wrong though.)
devel mailing list