Re: the way to enigmail: gnupg 2.1 backport considerations
On 2018-11-13 22:02:45, Ben Hutchings wrote:
> On Tue, 2018-11-13 at 12:31 -0500, Daniel Kahn Gillmor wrote:
>> On Mon 2018-11-12 15:16:39 -0500, Antoine Beaupré wrote:
>>
>> > * libgcrypt20 (part of GnuTLS, 1.6 -> 1.7)
>>
>> libgcrypt is not a part of GnuTLS. GnuTLS has used nettle instead of
>> gcrypt for years. gcrypt is more properly "part of GnuPG" than anything
>> else.
>>
>> basically, all of these libraries are gnupg libraries.
>>
>> It's a little bit distressing that upstream's attempt to split them out
>> as distinct libraries (which i think was intended to make them more
>> useful to other consumers) might be a roadblock on the way to updating
>> GnuPG itself.
>>
>> Ben's suggestion of shipping them in a non-default location ("vendor
>> bundling"?) sounds pretty dubious to me -- i wouldn't want to reason
>> about (let alone vouch for) the upgrade path from such a hybridized
>> variant of jessie to standard debian stretch myself.
>
> I was thinking that those libraries would be included in the same
> binary package as /usr/bin/gpg2 and other executables, which would all
> have a run-path set. No-one should need to set LD_LIBRARY_PATH so no
> other executables would use those libraries, and the libraries would be
> removed when the executables that use them are removed or replaced.
>
> Since gnupg2 actually spreads executables across multiple binary
> packages, I realise the libraries would have to be an additional binary
> package and that would remain after an upgrade. But it would be
> harmless cruft that "apt autoremove" would deal with.
>
> (I assume that GnuPG 2.1 would be packaged as "gnupg2", replacing GnuPG
> 2.0 since that is no longer supported upstream. If not then I do see a
> problem of how to make, say, gnupg2.1 in jessie upgrade to gnupg2 in
> stretch. But that's independent of the library issue.)
I think this is overengineered. I still haven't heard exactly what the
problem would be with upgrading those libraries. They are present in
jessie-backports and presumably well tested. They are rarely directly
consumed by third-parties and mostly encapsulated behind GPGME, at least
that's my understanding. The SONAMEs don't change, so they should be
backwards compatible anyways.
Right?
Doing otherwise would be a massive change and would mean we would be
maintaining multiple copies of those four libraries in jessie, and in an
obscure location as well. I don't know how we would proceed to do this
as source packages anyways - would they all get merged into the gnupg2
source package?
In any case, I don't feel confident starting down that path and I'm
running out of time for the month, so I'll let others figure that out
for the next two weeks.
A.
--
Premature optimization is the root of all evil
- Donald Knuth
Reply to: