On 2018-01-11 23:07:32 [+0200], Adrian Bunk wrote: > On Thu, Jan 11, 2018 at 09:39:51PM +0100, Sebastian Andrzej Siewior wrote: > >... > > since everything not > > shipped Debian wise would be suddenly linked againt libssl-1.1 while it > > might have been compiled against an earlier version. > > The handling of non-packaged software is not perfect, but there's > precedent for changing the package name without changing the soname > (e.g. check the conflicts of the libstdc++6 package in stretch).
does it mean you are pro different package name but keeping the soname? > > Maybe it would be wise to suggest to upstream to bump major 4 to a 5 to > > signal that this libcurl exposes the libssl1.1 ABI now. > > "now" was 2016. now was not 2016. Debian didn't have curl compiled against 1.1 shipped anywhere. Don't know about Suse but Fedora had the same soname and linked against nss instead of libssl [0]. - fc26 had libcurl compiled against nss [1] - fc27 had libcurl compiled against libssl1.1 [2] > Back then this would have been a valid point, but after other > distributions already ship with OpenSSL 1.1 and the old libcurl > soname it is too late for that. if the package maintainer agrees, he can ask upstream. Worst thing is that they say no. > The package name is the only thing we can change without diverging from > other distributions. but the only reason why one wants to keep the same soname is to use binaries from another distro/precompiled binary only code from "vendor". Or do I miss something else? [0] https://fedoraproject.org//wiki/Changes/libcurlBackToOpenSSL [1] http://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/26/Everything/x86_64/os/Packages/l/libcurl-7.53.1-7.fc26.x86_64.rpm [2] http://ftp-stud.hs-esslingen.de/pub/fedora/linux/releases/27/Everything/x86_64/os/Packages/l/libcurl-7.53.1-7.fc26.x86_64.rpm > cu > Adrian Sebastian
