Re: 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 +, 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

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Re: Proposed (lib)curl switch to openssl 1.1

[Alessandro Ghedini]

On Sat, Dec 02, 2017 at 06:09:39PM +0100, Julien Cristau wrote:
> On Thu, Nov 23, 2017 at 15:49:26 +, 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.

Due to the fact that the previous transition (libcurl3 -> libcurl4) was
partially reverted (in 2007 according to the changelog), I'd also like to
taeke this opportunity to finally complete that as well, so I made a patch
to not only rename libcurl3 -> libcurl4, but also (libcurl3-gnutls,
libcurl3-nss) -> (libcurl4-gnutls, libcurl4-nss), and remove the hacks needed
to keep compatibility with the previous ABI.

Thoughts?

The patch is at https://salsa.debian.org/debian/curl/merge_requests/2

CHeers


signature.asc
Description: PGP signature
__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.

Re: Proposed (lib)curl switch to openssl 1.1

[Julien Cristau]

On Thu, Nov 23, 2017 at 15:49:26 +, Ian Jackson wrote:

> (Resending to fix the mail headers, sorry.  Please reply to this one,
> not the previous one.)
> 
> Hi.  You're receiving this mail because you fall into one or more of the
> following categories:
>  * Are associated with the curl package (To)
>  * Have been involved in discussions I found in the BTS about
>libcurl and openssl 1.1 (CC), eg in #850880 or #844018
>  * Maintain a package which calls CURLOPT_SSL_CTX_FUNCTION
>(CC, "CURLOPT_SSL_CTX_FUNCTION callers")
>  * Are the Release Team (To, see bullet point 3 below)
> 
> We really need to migrate libcurl to openssl 1.1.  This is #858398,
> which has not seen activity from any libcurl maintainers.
> 
> I am listed as an Uploader for curl but I haven't done a curl upload
> and don't really understand the issues well.  But, as far as I
> understand it, the right thing to do is just to change the
> build-dependencies.
> 
> I have prepared a patch to do this and intend to upload it to sid on
> Sunday unless someone explains to my why it's a bad idea.  See below.
> 
Thanks for moving this forward.

> 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.

Cheers,
Julien

__
This is the maintainer address of Debian's Java team
. 
Please use
debian-j...@lists.debian.org for discussions and questions.