On Thu, Jul 21, 2016 at 8:31 PM Brian C. Lane <b...@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.
-- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
