Re: Proposed (lib)curl switch to openssl 1.1
- To: Alessandro Ghedini <ghedo@debian.org>
- Cc: Ian Jackson <ijackson@chiark.greenend.org.uk>, curl@packages.debian.org, debian-release@lists.debian.org, Sebastian Andrzej Siewior <sebastian@breakpoint.cc>, 858398@bugs.debian.org, Niels Thykier <niels@thykier.net>, Stepan Golosunov <stepan@golosunov.pp.ru>, Jan Niehusmann <jan@gondor.com>, Adrian Bunk <bunk@stusta.de>, cargo@packages.debian.org, chromium-browser@packages.debian.org, cmake@packages.debian.org, criticalmass@packages.debian.org, curlpp@packages.debian.org, firefox@packages.debian.org, firefox-esr@packages.debian.org, fpc@packages.debian.org, hhvm@packages.debian.org, icedove@packages.debian.org, lastpass-cli@packages.debian.org, libapache2-mod-auth-cas@packages.debian.org, libwww-curl-perl@packages.debian.org, lua-curl@packages.debian.org, netcdf@packages.debian.org, netsurf@packages.debian.org, openjfx@packages.debian.org, r-cran-curl@packages.debian.org, r-cran-rcurl@packages.debian.org, ruby-curb@packages.debian.org, slcurl@packages.debian.org, sx@packages.debian.org, tclcurl@packages.debian.org, wpa@packages.debian.org, xmltooling@packages.debian.org, zurl@packages.debian.org
- Subject: Re: Proposed (lib)curl switch to openssl 1.1
- From: Julien Cristau <jcristau@debian.org>
- Date: Thu, 11 Jan 2018 10:29:02 +0100
- Message-id: <[🔎] b4e74ff9-6ac3-54c1-c510-34a4cfd849bf@debian.org>
- In-reply-to: <20180110235920.GA18737@pinky>
- References: <23062.60934.23858.571216@chiark.greenend.org.uk> <20171202170939.x5a25grq5sa7w4wl@betterave.cristau.org> <20180110235920.GA18737@pinky>
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
Reply to: