Duane> I want to report a problem and a work around for LIBCURL on Ubuntu 18 -

Daniel> tl;dr: This is a Ubuntu / Debian issue, not a libcurl one.

Daniel> Back in September 2006 (yes, over twelve years ago)

Wow - thanks for the details, and context - its an ugly problem for me.

Hopefully my post/solution will help others understand or find a way to work around this problem.

________________________________
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, October 18, 2018 11:56:19 PM
To: Duane Ellis via curl-library
Cc: Duane Ellis
Subject: Re: BUG / PROBLEM libcurl3 vrs libcurl4 - Ubuntu 18 64bit.

On Fri, 19 Oct 2018, Duane Ellis via curl-library wrote:

> I want to report a problem and a work around for LIBCURL on Ubuntu 18 -
>
> The problem is outlined and detailed here:
>
> https://github.com/GitTools/GitVersion/issues/1508
>
> The there is breakage between "apt-get install libcurl3" - and "apt-get
> install libcurl4" - things break,

tl;dr: This is a Ubuntu / Debian issue, not a libcurl one.

The longer explanation:

In the libcurl project we take ABI and API stability very seriously. We don't
break them without a lot of consideration. We also primarily ship source code
and we don't build nor provide the packages for distributions like Ubuntu or
Debian.

Back in September 2006 (yes, over twelve years ago) we bumped the SONAME for
libcurl to 4 since we removed some functionality (third party FTP transfers)
and to not hurt applications relying on that feature we increased the number
from 3 to 4.

In a following discussion, the Debian people maintained that the libcurl
change was not "enough" to warrant an SONAME bump that according to them would
be very troublesome and hurt users or whatever. They thus patched their
libcurl build to stick at SONAME 3. It was their decision and they were of
course allowed to do that they thought was correct. Ubuntu inherited this
setup from Debian.

I'm not aware of any other Linux distribution or operating system packages
that took a similar decision, so the rest of the world followed our lead and
went to SONAME 4.

Fast forward some eleven years or so.

When OpenSSL shipped (I believe) version 1.1.0, the Debian project figured out
that libcurl has a callback (CURLOPT_SSL_CTX_FUNCTION) that gets a pointer
passed to it, and when built to use OpenSSL this pointer is a "SSL_CTX *"
pointing to an objected own and defined by OpenSSL. They deemed that with
1.1.0, the contents this pointer points to was changed and should warrant a
libcurl ABI number bump.

(I should add that this is stuff I've mostly picked up from discussions on
their bug trackers, I haven't really researched this area enough myself.)

So, an SONAME bump was deemed necessary by Debian and they bumped it to 4 and
now they're aligned with us again.

Again it can be noted that I've not spotted any other distro doing this SONAME
bump.

Different sonames were invented to allow libraries to exist in parallel with
different versions to allow older applications to stick to the old lib while
you can install newer versions that use the more recent library.

Package managers however are usually less good at allowing systems to install
multiple parallel versions and they tend to say that if you install version
N+1, you remove version N. I think this is where this Ubuntu problem lies.

This problem and the solution to it, seems to be entirely outside of the curl
project's realm. If I'm wrong, I hope someone tells me.

--
  / daniel.haxx.se

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-10-19