On 2014-05-06 Dimitri John Ledkov <x...@debian.org> wrote: > On 5 May 2014 18:53, Andreas Metzler <ametz...@bebt.de> wrote: > > Didier 'OdyX' Raboud <o...@debian.org> wrote: > >> Le dimanche, 4 mai 2014, 02.14:17 peter green a écrit : > >>> Personally I'd add a (build-)depends on the relicensed gmp in the next > >>> gnutls28 upload. That way packages can (build-)depend on the new > >>> gnutls and be assured of getting a GPLv2 compatible version. [...] >> Also I am reluctant with manually overriding gmp shlibs. How about >> simply adding >> Breaks: libgmp10 (<< 2:6) >> to the libgnutls28 binary package? >> [...]
FWIW I have now used Peter's original suggestion [1], the dependency is clearer this way (less work for apt), and the Breaks would have needed manual intervention on a GMP soname bump, too. [...] >> I have done some test-builds and reported most of the issues I >> found[1]. Some important library packages have already switched (cups, >> curl), I guess the next one would be neon or gnome-vfs. > =/ i was hoping that it's api compatible, so we can't just blindly > take-over previous libgnutls-dev package name from gnutls28 sources [...] It is mostly compatible, some deprecated functions have been removed. Most of the problem are caused by the fact that GnuTLS uses nettle instead of gcrypt now. * Packages that directly use gcrypt without an explicit b-d but relying on gnutls to pull it in. As gnutls28 does not use gcrypt, it is not available and we get FTBFS. Most of these only use one or two gcrypt functions (e.g. md5), choosing gcrypt simply because it was pulled in by gnutls anyway. These cases would benefit from conversion to the gnutls crypto API to strip down the dependency tree. * Packages which only use gcrypt directly to select thread locks. The respective header inclusion, gcry_control(...) and linking against gcrypt should be made conditional on gnutls << 2.12 [2] > Are you talking about 3.2.13-2 or 3.3.1-1 from experimental or both > that things need fixing up to support? > Looking at the bugs it looks like either. I have done my test builds on 3.2.13. 3.3.* is API and ABI compatible, I will probably give it another one or two upstream releases before targeting unstable. cu Andreas [1] http://anonscm.debian.org/gitweb/?p=pkg-gnutls/gnutls.git;a=commitdiff;h=05701c956b08c92d7bdde199c987136d32448c5d [2] Quoting from NEWS: ** libgnutls: Added gnutls_global_set_mutex() to allow setting alternative locking procedures. By default the system available locking is used. In *NIX pthreads are used and in windows the critical section API. This follows a different approach than the previous versions that depended on libgcrypt initialization. The locks are now set by default in systems that support it. Programs that used gcry_control() to set thread locks should insert it into a block of #if GNUTLS_VERSION_NUMBER <= 0x020b00 gcry_control(...) #endif -- `What a good friend you are to him, Dr. Maturin. His other friends are so grateful to you.' `I sew his ears on from time to time, sure' -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140507181107.ga2...@downhill.g.la