On Fri, Dec 08, 2017 at 05:44:55PM +0100, Ondřej Surý wrote:
> Hi,
>
> just innocent bystander here with an observation:
>
> These two options:
>
> a)
> > I do agree it's the correct solution though, and it would be a good
> > opportunity
> > to finally sync SONAME with upstream
>
> b)
> > Because of 1 I think we should change the package name (and SONAME) for
> > libcurl3. I don't think 2 is appropriate.
>
> are mutually exclusive, so even if we rename the share library packages
> to libcurl4*, they would have to conflict with libcurl3* because they
> would contain same files.
>
> And the SONAME is already libcurl.so.4 (at least on stretch):
>
> $ objdump -p /usr/lib/x86_64-linux-gnu/libcurl* | grep SONAME
> SONAME libcurl-gnutls.so.4
> SONAME libcurl-gnutls.so.4
> SONAME libcurl-gnutls.so.4
> SONAME libcurl.so.4
> SONAME libcurl.so.4
> SONAME libcurl.so.4
>
> So in this case, unfortunately, bumping the SONAME is actually something
> different than changing package name to match to SONAME of the library.
>...
Similar to all the v5 postfixed packages in Debian for C++ ABI changes
in GCC 5, what matter here is actually not the SONAME but the package
name and that the new package conflicts with the old package.
This is sufficient to fix the issue for all packages using curl.
And different from breaks on specific packages, it will also force an
upgrade of packages from backports.
Non-packaged software is a different topic, but the whole OpenSSL
situation in stretch is already a mess for that.
This whole transition looks pretty straightforward to me,
please let me know if there is anything where I could help.
> Ondrej
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
