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

[Till Maas]

Hi,

On Tue, Oct 10, 2017 at 09:55:29AM -0700, Brian C. Lane wrote:

> 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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Christopher]

On Wed, Oct 11, 2017 at 4:09 AM Tomas Mraz  wrote:

> On Wed, 2017-10-11 at 05:33 +, Christopher wrote:
> > On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> > domi...@greysector.net> wrote:
> >
> > > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane 
> > > > wrote:
> > > >
> > > > > 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 - https://dev.gnupg.org/T3443
> > > > > Discussion -
> > > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > > 51.html
> > > > >
> > > > > 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.
> > > > >
> > > >
> > > > 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.
> > >
> > > Alternatives are for things that are drop-in replacements. As far
> > > as I
> > > know, gpg2 is not a drop-in replacement for gpg1.
> > >
> >
> > 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.
>
> I think that the incompatibility of the key storage warrants for not
> using the alternatives system in this case.
>
>
The alternatives system is there to provide choice between different
implementations. The fact that they have different implementations of their
backend storage is not a reason to avoid alternatives... it's a reason to
use it to provide users a choice. Not using alternatives is just going to
make it harder for users to switch back to gpg1 when gpg2 is made the
default gpg, if a user needs to continue using the old storage format. It
won't affect me, though. I'll be using gpg2, regardless. I was just
thinking of trying to support those other users who need/want to stay on
the old implementation.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Tomas Mraz]

On Wed, 2017-10-11 at 05:33 +, Christopher wrote:
> On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> domi...@greysector.net> wrote:
> 
> > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane 
> > > wrote:
> > > 
> > > > 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 - https://dev.gnupg.org/T3443
> > > > Discussion -
> > > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/0331
> > > > 51.html
> > > > 
> > > > 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.
> > > > 
> > > 
> > > 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.
> > 
> > Alternatives are for things that are drop-in replacements. As far
> > as I
> > know, gpg2 is not a drop-in replacement for gpg1.
> > 
> 
> 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.

I think that the incompatibility of the key storage warrants for not
using the alternatives system in this case.

-- 
Tomáš Mráz
Red Hat

No matter how far down the wrong road you've gone, turn back.
  Turkish proverb
[You'll know whether the road is wrong if you carefully listen to your
conscience.]

 * Google and NSA associates, this message is none of your business.
 * Please leave it alone, and consider whether your actions are
 * authorized by the contract with Red Hat, or by the US constitution.
 * If you feel you're being encouraged to disregard the limits built
 * into them, remember Edward Snowden and Wikileaks.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Christopher]

On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
domi...@greysector.net> wrote:

> On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane  wrote:
> >
> > > 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 - https://dev.gnupg.org/T3443
> > > Discussion -
> > > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
> > >
> > > 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.
> > >
> >
> > 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.
>
> Alternatives are for things that are drop-in replacements. As far as I
> know, gpg2 is not a drop-in replacement for gpg1.
>

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane  wrote:
> 
> > 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 - https://dev.gnupg.org/T3443
> > Discussion -
> > https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
> >
> > 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.
> >
> 
> 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.

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
-- 
Fedora   https://getfedora.org  |  RPMFusion   http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
-- from "Collected Sayings of Muad'Dib" by the Princess Irulan
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Christopher]

On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane  wrote:

> 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 - https://dev.gnupg.org/T3443
> Discussion -
> https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html
>
> 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.
>

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

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

[Brian C. Lane]

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 - https://dev.gnupg.org/T3443
Discussion - 
https://lists.gnupg.org/pipermail/gnupg-devel/2017-October/033151.html

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

-- 
Brian C. Lane (PST8PDT)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org