On Mon, 19 Nov 2018, Antoine Beaupré wrote:
> 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.
I can't stress thos often enough. Jessie-backports doesn't exist anymore.
They are unsupported for months and I do really hope that they get archived
soon.
Do NOT use it.
Alex - Debian Backports ftpmaster
