On Tue 2018-11-20 15:47:00 +0000, Ben Hutchings wrote: > On Tue, 2018-11-20 at 10:28 -0500, Antoine Beaupré wrote: >> On 2018-11-20 15:19:45, Ben Hutchings wrote: >> > On Mon, 2018-11-19 at 15:48 -0500, Antoine Beaupré wrote: > [...] >> > > 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. >> > [...] >> > >> > Those updated library packages are installed and used by people that >> > specifically choose to use GnuPG 2.1 in jessie. I don't think we can >> > assume they are well-tested in conjunction with GnuPG 1.4. >> >> My understanding is that GnuPG 1.4 does not use those libraries at all, >> and from what I can tell, gpg 1.4 does not link against them either. > > Oh! I don't know why I thought it did. Then this does seem like a > reasonable approach.
Just confirming Anarcat's comment here. GnuPG's classic branch (1.4.x)
is a monolithic build, and does not depend on any of the libraries in
question. Those libraries are used by GnuPG 2.0.x and later.
The main place where you'll find them used is:
* things that use gcrypt directly (e.g. cryptsetup)
* things that use gpgme (e.g. gmime)
As Anarcat suggests, i believe that upstream intends the lack of an
SONAME bump to mean that they should be cleanly upgradable.
I'm not super confident in upstream's ability to maintain a stable API,
sadly. For example, some of the libraries in question -- like gcrypt --
do a lot with string-passing between the main application and the
library, which means that they don't expose API changes via function
call entrypoints, which is how debian is best at doing simple API
tracking (e.g. .symbols files). There are also data structures in some
libraries (like gpgme) that are exposed directly, but that the user is
expected to receive pointers to from the library, but not to directly
instantiate (and yes, sometimes those data structures do grow over time,
though i don't think i've ever seen them actually change in a
backward-incompatible way across a release). The library documentation
is often sparse about which data structures the users are expected to
avoid instantiating directly, though upstream is usually pretty good
about providing feedback to developers who ask questions on the
gnupg-de...@gnupg.org mailing list.
All that said, i don't think that upgrading jessie to the versions of
these libraries that are in debian stretch will break jessie. I do wish
we had more substantive autopkgtest-style coverage in jessie, so that we
could feel more confident about this, but i don't think we currently do.
--dkg
signature.asc
Description: PGP signature
