Hi, (Cc to Alessandro because this causes issues with libcurl)
On Wed, Nov 02, 2016 at 09:15:13PM +0100, Kurt Roeckx wrote: > I don't think having libssl1-1-dev vs libssl1.0-dev is going to > make much differences in the end. The build conflicts will always > have to be sorted out. Well I think it makes a difference: With libssl-dev silently switching to OpenSSL 1.1, packages get recompiled with the new version, but the maintainers may be unaware that this causes compatibility issues. I have a concrete example: It seems like the package zurl is broken by libcurl3 being linked with OpenSSL 1.1. This means the binary package zurl 1.7.0-1 works fine with libcurl3 7.50.1-1, but fails to connect to https URLs when libcurl3 is upgraded to 7.51.0-1. (It also works with curl 7.51.0-1 recompiled with OpenSSL 1.0, so I'm quite sure it's actually caused by the OpenSSL transition.) So, in short, upgrading libcurl3 breaks existing binary packages. According to our policy, that means a SONAME change would be necessary. ("Every time the shared library ABI changes in a way that may break binaries linked against older versions of the shared library, the SONAME of the library and the corresponding name for the binary package containing the runtime shared library should change.") But the way the OpenSSL transition was communicated, Alessando probably didn't expect that the change would cause an ABI change. How do we handle this? For this single package, zurl, I could recompile with OpenSSL 1.1. This seems to work, but I'm not sure if there are hidden issues, as zurl also links to qt5, which is built against libssl1.0-dev. But who knows which other packages are silently broken the same way? Jan