gnutls28 (that is GnuTLS 3.x) has been available in experimental for
quite some time. While the API breakage compared to gnutls26 (2.x) is
not too bad, there are two major issues:
* It uses nettle instead of gcrypt as crypto backend. Packages that
directly use gcrypt will need an additional build-dependency. Also
quite a lot packages use special code for thread locking which needs
to be replaced/deleted/whatever.
* The new version uses LGPLv3+/GPLv3+ instead of v2+, and can
therefore not be used in GPLv2 projects anymore. (Hello, cups!)
Because of these issue I think that I should not upload gnutls28 to
unstable and build libgnutls-dev from the gnutls28 version. Building
against the new version should only happen if the maintainer of the
depending package has doublechecked bothat that he/she may use
gnutls28 and that the package still works. Therefore I plan to use a
versioned name for the development package (libgnutls28-dev) when
uploading to unstable.
The obvious downside is that we will have two versions in unstable
(and probably even in squeeze). At least we are using versioned
Thoughts/comments/magic bullet anyone?
thanks, cu andreas
PS: X-posted to -devel and -release, please followup to devel. I am
 Actually even for 2.12.x nettle is the prefered crypto backend.
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact email@example.com
10-15-2011, 06:31 PM
RFC transitioning to gnutls28
On Oct 15, Andreas Metzler <firstname.lastname@example.org> wrote:
> * It uses nettle instead of gcrypt as crypto backend. Packages that