Proposed (lib)curl switch to openssl 1.1

[Julien Cristau]

On 01/11/2018 12:59 AM, Alessandro Ghedini wrote:
> On Sat, Dec 02, 2017 at 06:09:39PM +0100, Julien Cristau wrote:
>> On Thu, Nov 23, 2017 at 15:49:26 +0000, Ian Jackson wrote:
>>> Reasons I am aware that it *might* be a bad idea are:
>>>
>>> 1. libcurl exposes parts of the openssl ABI, via
>>>    CURLOPT_SSL_CTX_FUNCTION, and this would be an implicit ABI break
>>>    without libcurl soname change.  This is not good, but it seems like
>>>    the alternative would be to diverge our soname from everyone else's
>>>    for the same libcurl.
>>>
>>> 2. For the reason just mentioned, it might be a good idea to put in a
>>>    Breaks against old versions of packages using
>>>    CURLOPT_SSL_CTX_FUNCTION.  However, (a) I am not sure if this is
>>>    actually necessary (b) in any case I don't have a good list of all
>>>    the appropriate versions (c) maybe this would need coordination.
>>>
>>> 3. This might be an implicit a "transition" (in the Debian release
>>>    management sense) which I would be mishandling, or starting without
>>>    permission, or something.
>>>
>> Because of 1 I think we should change the package name (and SONAME) for
>> libcurl3.  I don't think 2 is appropriate.
> 
> Following discussion on the ticket (#858398) it was suggested to follow the
> strategy used for the GCC 5 C++ ABI transition, that is, rename the libcurl
> package and add Conflicts+Replaces for teh old package.
> 
I still think that is a terrible idea and we're better off with both a
new SONAME and a new package name.  Conflicts in core libraries turn the
upgrade path to hell.

Cheers,
Julien