On Fri 2021-03-05 10:21:37 -0500, Daniel Kahn Gillmor wrote: > It's not clear to me that the proposed upstream API is particularly easy > to use, but maybe it's better to drop the remaining patch and align with > upstream expectations, because: > > - the test suite already has dropped coverage of the relevant parts, > so the test suite won't fail. > > - in T4820, upstream appears concerned about additional compute cost of > generating keygrips (though i haven't seen any attempt to > characterize the total compute cost) > > - alignment with upstream is good in itself > > One possible consequence of doing this this is that gpgme-dependent > tools that expect the keygrip field to be populated (as it indeed was by > default when gpgme was backed with older versions of gpg) may break > until they learn to apply GPGME_KEYLIST_MODE_WITH_KEYGRIP (which in turn > would oblige them to depend on gpgme >= 1.14.0). > > Another alternative would be to make > debian/patches/0006-gpg-Send-with-keygrip-when-listing-keys.patch > conditional on the version -- only do that when the backend is known to > be version 2.2.x or higher. > > I'm leaning toward just dropping the patch.
So i've dropped the patch in debian experimental, but i haven't done anything for the version currently in unstable/testing. I'd be curious to hear other people's thoughts about whether it's right to make the change before the freeze for Debian bullseye as well. Arguments for trying to make the change for bullseye are described above. arguments for not making the change for bullseye include: - this seems to introduce gratuitous breakage for some tools that use gpgme, expect the keygrip, but don't know about GPGME_KEYLIST_MODE_WITH_KEYGRIP - it seems to be trying to support gpg1, which we are otherwise already trying to figure out how to phase out I'm unsure of the right tradeoff here, but i welcome input on it. --dkg
signature.asc
Description: PGP signature
