Re: gnutls28 transition
On 2014-05-06 Dimitri John Ledkov <xnox@debian.org> wrote:
> On 5 May 2014 18:53, Andreas Metzler <ametzler@bebt.de> wrote:
> > Didier 'OdyX' Raboud <odyx@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'
Reply to: