Re: OpenSSL 1.1.0
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
Reply to: