On Sun, 11 Sep 2005, Steve Langasek wrote:
We've already identified that the CURLOPT_SSL_CTX_FUNCTION option is of
negligible importance to Debian, and does not (from my POV) appear to
warrant a separate soname.
You couldn't find any debian-provided package that uses the option, but that
doesn't rule out that there are debian users out there who use programs that
use the option. Debian users and developers don't _always_ use everything from
Debian packages only you know.
The description of the other issue ("mutex/lock callbacks") doesn't give me
enough information as an outsider to understand why this has an effect on
the ABI. Can you elaborate?
To use libcurl with SSL-powers in a multi-threaded context, with libcurl use
in more than one thread, you need to set mutex callbacks in the underlying SSL
library. (Or in the GnuTLS case, the underlying underlying library! ;-O)
For exact details on how, please check the libcurl docs.
So, if you switch Debian to libcurl-gnutls ONLY as the involved libs work
today, you'll break all libcurl-using applications that:
1. Use SSLv2 (or any other features only provided by OpenSSL)
2. Use CURLOPT_SSL_CTX_FUNCTION
3. Does FTPS or HTTPS multi-threaded
(And most likely some other things that I have missed.)
Issue 1 is fixed by extending GnuTLS
Issue 2 is fixed by extending GnuTLS to get a similar feature, or possibly by
finding out that there already is one and then make libcurl use it.
Issue 3 is fixed by introducing a generic libcurl API for it
Mo one currently works on solving any of these issues, AFAIK.
--
-=- Daniel Stenberg -=- http://daniel.haxx.se -=-
ech`echo xiun|tr nu oc|sed 'sx\([sx]\)\([xoi]\)xo un\2\1 is xg'`ol
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
