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
