DevHeads.net

How should we handle gnupg v1.4.X as gpg1?

The time for change is finally, almost here :) Upstream is talking about
installing the v1.4 series as gpg1. They have already switched the
default install of 2.2 to /usr/bin/gpg, but we currently override this
with the --enable-gpg-is-gpg2 switch in gnupg2.

Tracker bug here - <a href="https://dev.gnupg.org/T3443" title="https://dev.gnupg.org/T3443">https://dev.gnupg.org/T3443</a>
Discussion - <a href="https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html" title="https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html">https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html</a>

When this happens I plan on tracking upstream's change and installing as
gpg1, but I'm pretty sure we need a plan so that things don't end up all
broken.

I'm not sure of all the corners where we use gpg so we need to track
those down and make a list of things that need changing. In some cases
using gpg 2.2.x will be fine, but I'm sure there will continue to be
cases where gpg1 is needed.

This would be for rawhide only of course, any updates to previous
releases would continue to use /usr/bin/gpg

Comments

Re: How should we handle gnupg v1.4.X as gpg1?

By Till Maas at 10/11/2017 - 12:42

Hi,

Awesome! It would be great if we continue to ship a gpg2 -> gpg symlink
to make it easier possible for tools to use gpg2.

Kind regards
Till

Re: How should we handle gnupg v1.4.X as gpg1?

By Christopher at 10/10/2017 - 13:57

Have you considered using alternatives as part of that plan, with gpg2 set
to higher priority than gpg1? Since upstream calls both binaries "gpg", it
kind of already makes sense to deconflict them with the alternatives system
in this way.

Re: How should we handle gnupg v1.4.X as gpg1?

By Dominik 'Rathan... at 10/10/2017 - 16:30

On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
Alternatives are for things that are drop-in replacements. As far as I
know, gpg2 is not a drop-in replacement for gpg1.

Regards,
Dominik

Re: How should we handle gnupg v1.4.X as gpg1?

By Christopher at 10/11/2017 - 00:33

On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <

I suppose it depends on which characteristics you're considering when you
compare the two. I can't be the only one who has noticed their command-line
usage similarities, which is the characteristic I would expect to matter
when considering using the alternatives system.

Re: How should we handle gnupg v1.4.X as gpg1?

By Tomas Mraz at 10/11/2017 - 03:00

On Wed, 2017-10-11 at 05:33 +0000, Christopher wrote:
I think that the incompatibility of the key storage warrants for not
using the alternatives system in this case.