On Thu, Jul 21, 2016 at 8:31 PM Brian C. Lane <bcl(a)redhat.com> wrote:
On Thu, Jul 21, 2016 at 07:57:47PM -0000, Christopher Tubbs wrote:
> This is still causing me headaches. GPG2 switched away from the
secring.gpg file, and now I have multiple tools using different files for
storing my credentials. And, depending on which command I use (sometimes I
slip and use gpg instead of gpg2), I import stuff to the wrong keyring, and
I can't find it later.
>
> That, combined with the fact that the gpg command doesn't use
gnome-keyring-daemon's gpg-agent without some extra ENV setup, and the git
bug from earlier in the thread, this is getting pretty annoying.
>
> Users can't uninstall gnupg and only use gnupg2, either, because
important stuffs depend on it, like anaconda, initial-setup, libblockdev-*,
monkeysphere, hplip, volume_key-libs (no idea why those last two should,
but they do).
>
> Being able to use alternatives without messing with package files which
are likely to get clobbered on update, would be nice, at the very least.
>
> But really, I think it's time to transition, since there's no technical
reason why one should be using gnupg1 these days.
>
> We could transition in this way:
>
> 1. Have packages depend on gnupg2 instead.
> 2. Rename gnupg to gnupg1
> 3. Make gnupg a meta-package which depends on gnupg2 and sets up
alternatives.
> 4. Make gpg1 lower priority in alternatives than gpg2 for /usr/bin/gpg
> 5. Don't install gnupg by default.
I don't see the point. Switching because you accidentally type the wrong
thing isn't a valid reason.
That wasn't the only reason given. The other reasons include:
* It doesn't provide anything that gpg2 doesn't already provide
* It doesn't properly integrate with gnome-keyring-daemon or the default
behavior of gpg-agent to use the "standard socket" out of the box, creating
a bad user experience
* It introduces unnecessary inconsistencies in where keys are stored, again
creating a bad user experience when trying to execute commands to display
stored keys
* There isn't a good mechanism provided for switching between the two, and
one cannot uninstall gpg without removing some important things which
depend on it
Upstream still ships and supports gpg, people (like me, the gpg
maintainer) still use it instead of gpg2 for various things. Until
upstream stops shipping it, or renames it, it should continue to be
called gpg.
I don't see a problem with continuing to ship it, but because of the bad
user experience with lack of using the "standard socket" and the
inconsistency in where it stores keys, it probably shouldn't be the default.
If you want gpg2, type gpg2. Problem solved and everyone is happy :)
Not everyone. See above thread... I'm not the only one who thought we
should move, and others cited precedents for packaging gpg2 as gpg from
other downstream maintainers.
I'm not arguing for complete removal... I'm just arguing for a change in
the default, and a packaging strategy which takes advantage of the
alternatives system, to give users a better way to choose, for a better
overall out-of-the-box user experience.
Essentially, gpg2 obsoletes gpg upstream... even if upstream continues to
support it. So, why not move? Given the bad user experience, it seems to me
that the argument for keeping it as is should be somewhat more than
sticking with the status quo.
Can you please explain why my proposal isn't a good compromise which
addresses the problems above, and still provides folks the option to use
gpg1? Is there a technical reason?
Thanks.