On Wed, Oct 11, 2017 at 4:09 AM Tomas Mraz <tmraz@xxxxxxxxxx> wrote:
On Wed, 2017-10-11 at 05:33 +0000, Christopher wrote:
> On Tue, Oct 10, 2017 at 5:44 PM Dominik 'Rathann' Mierzejewski <
> dominik@xxxxxxxxxxxxxx> wrote:
>
> > On Tuesday, 10 October 2017 at 20:57, Christopher wrote:
> > > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lane <bcl@xxxxxxxxxx>
> > > 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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
