[ trimmed Cc list ]
On Thu, Nov 23, 2017 at 01:57:58PM +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.
Without a soname change it cannot be avoided that non-packaged software
gets broken due to this change, the best available way to mitigate might
for such software would be a NEWS.Debian entry (and perhaps mentioning
in the buster release notes).
> 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.
> (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.
> (c) maybe this would need coordination.
The best way that avoids breakages in testing and also handles all
stretch -> buster upgrade situations including packages in
stretch-backports would a rename of libcurl3 with Conflicts+Replaces on
libcurl3, similar to the v5 postfixed packages when the C++ ABI slightly
changed in gcc 5.
> 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.
>...
What I suggest above would be a transition that should be coordinated
with the release team like other transitions.
cu
Adrian
--
"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
