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/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@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
