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.)
Ben.
--
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot
Attachment:
signature.asc
Description: This is a digitally signed message part