[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: curl 7.14.0-5: OpenSSL vs GnuTLS is still a problem

On Wed, Aug 24, 2005 at 03:54:38PM +0200, Domenico Andreoli wrote:
> On Fri, Aug 19, 2005 at 12:07:09PM +1000, Paul TBBle Hampson wrote:
>> On Thu, Aug 18, 2005 at 11:00:41AM +0200, Domenico Andreoli wrote:
> >>   with curl 7.14.0-5 currently in incoming, i added two new packages
> >> libcurl3-gnutls and libcurl3-gnutls-dev. libcurl3 and libcurl3-gnutls
> >> conflict each other since both install libcurl.so.3.0.0 in /usr/lib/.
>> If the problem is that using gnutls or openssl changes the ABI for libcurl,
>> then they should have different sonames. (I'd expect the newer one, gnuTLS,
>> would get its own soname, so that existing packages work, and packages can
>> optionally build against the gnuTLS version if they so wish. Once everything
>> builds happily against the gnuTLS version, the next upstream soname bump can
>> use the gnuTLS library, and we're compatible with other distributions again.)

> problem is right the change of ABI.

> Daniel Stenberg (the upstream developer) is available to implement a
> solution based on the proposal of Richard Atterer [0].

The issue in the above is that the suggestion of two different versions of
libcurl being a problem for prog A is only a problem if the sonames/sovers are
not differentiated, and I suggest they _be_ differentiated. I mean, they
provide different ABIs. Will the openSSL version provide dummy gnuTLS entries
as well?  And what about a different ssl implementation? pssl, or whatever it's
called?  If you want to have one ABI no matter which libraries are being used,
then you need to provide an ABI that abstracts away anything SSL, and doesn't
require the curl-using program to care what it's linked against. _Then_ you
provide a pair of curl packages, one with openSSL and one with gnuTLS, same
soname and sover, both providing libcurl3, and programs that need the
functionality of the openSSL version can conflict with the libgnutls version of
the library, and programs that don't care can use either. However, that's not a
huge improvement over now, while my below suggestion allows GPL'd curl-using
programs to be uploaded without having to remove openssl-needing curl-using

> in the meanwhile new packages can be built using the gnutls variant of
> libcurl3. be aware that libcurl3 and libcurl3-gnutls currently cannot
> be installed at the same time.

I'd again suggest changing the soname of the gnuTLS libcurl to something else,
since the changed ABI means that programs must choose to build against one or
the other, and so it's not a problem if programs need to be told to link
against libcurl-gnutls3.so instead of libcurl3.so, since presumably no other
distro is trying to simultaneously support both openSSL and gnuTLS versions of
libcurl, which is the strongest motivation for keeping upstream's soname. ^_^

And then the two packages can be parallel-installed, avoiding this particularly
nasty issue in this proposed solution. I cannot see what motivation there is to
only have one of the library pacakges installed. The _dev_ packages need to
conflict as they provide the same API, of course.

This also means you need to produce a -dev pacakge for both libcurl and
libcurl-gnutls. Those programs that know they need the gnuTLS version of
libcurl can build-depend on libcurl-gnutls-dev and so they'll have
libcurl-gnutls.so.3 in their library load list instead of libcurl.so.3.

Programs which are unhampered by licenses can try out the gnuTLS version, and
if it works, the can use that, or stick with the openSSL version until the
gnuTLS version matures and can fully replace the openSSL version as
libcurl.so.4. (And a bit of trickery with the libcurl-gnutls4-dev would mean
anything built against that gets the unified libcurl4 dependancy.)

The _important_ point is that no pair of programs becomes uninstallable due to
conflicts between their dependant curl library versions.

I'm not sold on the idea of run-time dynamic choosing of openSSL vs a stub, and
for that matter it means the issue of curl-config --features (my bug report
from way back when) becomes a lot more complicated.

Paul "TBBle" Hampson, MCSE
8th year CompSci/Asian Studies student, ANU
The Boss, Bubblesworth Pty Ltd (ABN: 51 095 284 361)

"No survivors? Then where do the stories come from I wonder?"
-- Capt. Jack Sparrow, "Pirates of the Caribbean"

License: http://creativecommons.org/licenses/by/2.1/au/

Attachment: pgplPNPSq75yZ.pgp
Description: PGP signature

Reply to: