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 <[email protected]> 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
