On Thu, Dec 20, 2018 at 2:23 PM Rex Dieter <rdieter@xxxxxxxxx> wrote: > > Dominik 'Rathann' Mierzejewski wrote: > > > On Thursday, 20 December 2018 at 08:15, Panu Matilainen wrote: > >> On 12/19/18 4:31 PM, John Harris wrote: > >> > On Wednesday, December 19, 2018 5:10:21 AM EST Bruno Wolff III wrote: > >> > > gnupg2 is now obsoleting gnupg and the previous gpg command is not > >> > > available. > > [...] > >> > I can't believe this was done without using the alternatives system! > >> > >> Alternatives is not a solution, it's trouble looking for opportunities to > >> make more. > >> > >> There are a handful of cases where it is appropriate, but using > >> alternatives means retaining support for all of the variants throughout > >> the distro. That's pretty much the opposite direction from obsoleting, > >> which is the purpose here. > > > > Moreover, gpg2 is not option-compatible with gpg1, so using alternatives > > is not a good idea for this reason, either. > > The same argument could be used to support not changing what 'gpg' points to > (gpg v1 vs v2) as well. > > -- Rex I agree with Rex. Not 100% option-compatible isn't a great argument against using symlinks to a binary when you're already willing to swap out the binary itself. I think it makes sense to use alternatives for 'gpg', with the default being gpg2. Besides, the two are at least as "option-compatible" as 'java', 'mta', and 'go', and other tools which have different options between versions but still use alternatives. If the expectation to use alternatives is that they are 100% option-compatible, that would exclude pretty much everything a user might want to use alternatives for. A more reasonable expectation is that they are "generally" option-compatible, and this is certainly the case with gpg2, which preserves a lot of the gpg1 options, especially the most common ones to sign, verify, and manage trust and keyring contents. _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
