Re: Proposed (lib)curl switch to openssl 1.1
Control: block 858927 by -1
On Fri, Nov 24, 2017 at 12:26:20AM +0100, Sebastian Andrzej Siewior wrote:
> On 2017-11-23 17:09:09 [+0200], Adrian Bunk wrote:
> > On Thu, Nov 23, 2017 at 01:57:58PM +0000, Ian Jackson wrote:
> > > 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
> >
> > See #846908 for an example where it is necessary.
> #844018 has some history and was the reason for curl to stay with 1.0
>
> > > (b) in any case I don't have a good list of all
> > > the appropriate versions
> >
> > Kurt did search for affected packages a year ago,
> > so the information about affected packages in
> > stretch should already be available.
> >
> > Note that such Breaks won't work for backported packages.
>
> I did a grep and it seems that all affected users are blocked by
> #858398 except for hhvm. All of them seem to touch
> CURLOPT_SSL_CTX_FUNCTION and ask for libssl1.0-dev.
>
> I skipped some others (while doing the grep just now) which should not
> be an issue (like `cargo' but it depends on libssl-dev and
> libcurl4-gnutls-dev or `sx' which uses it only in its configure script
> or `cmake', r-cran-rcurl, curlpp which do not link against libssl,…).
So if we want to keep the soname, the Breaks would be on[1]:
hhvm (<< 3.21.0+dfsg-2.1)
lastpass-cli (<< 1.0.0-1.3)
libapache2-mod-auth-cas (<< 1.1-2.2)
netsurf-fb (<< 3.6-3.2)
netsurf-gtk (<< 3.6-3.2)
libxmltooling7 (<< 1.6.2-1.1)
zurl (<< 1.9.0-1.1)
> Sebastian
cu
Adrian
[1] I'm assuming there will be no unrelated uploads,
<< -2.1 works no matter whether the OpenSSL 1.1 upload
will be -2.1 or -3 or -1 of a new upstream version
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
Reply to: