Re: How should we handle gnupg v1.4.X as gpg1?
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?
On Wed, Oct 11, 2017 at 4:09 AM Tomas Mrazwrote: > 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?
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?
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. Lanewrote: > > > > > 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?
On Tuesday, 10 October 2017 at 20:57, Christopher wrote: > On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lanewrote: > > > 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?
On Tue, Oct 10, 2017 at 1:04 PM Brian C. Lanewrote: > 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?
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