Re: OpenSSL 1.1.0
On Tue, Nov 15, 2016 at 10:43:07AM -0300, Lisandro Damián Nicanor Pérez Meyer wrote:
> On lunes, 14 de noviembre de 2016 22:16:25 ART Jan Niehusmann wrote:
> [snip]
> > (It's fine if packages which depend on libssl-dev get an RC-bug if they
> > can't be compiled with OpenSSL 1.1. Packages which can't be ported
> > should explicitly depend on libssl1.0-dev. That way we'll make progress
> > towards a point where we can start a smooth transition.)
>
> I *really* disagree with that. Swtiching libssl-dev to provide libssl1.1-dev
> means that some apps/libs will get automatically recompiled and some of them
> might even not FTBFS (because for example, they are ready to use 1.1).
>
> That means we left the door open to crashes due to mixed libssl versions.
I probably didn't state that clear enough: I don't think libssl-dev
should provide libssl1.1-dev.
But building packages - purely for testing purposes - against
libssl1.1-dev and reporting any issues is a good thing, and I even think
such bugs could be marked RC, to make sure we make progress.
At the same time, I don't want to remove packages which can't be ported
quickly. Therefore, either these bugs can't be RC, or there must be an
easy way for maintainers to opt out. One way of such an opt-out would be
changing the dependency to libssl1.0-dev.
However, the quoted paragraph was meant as a side-note only. It's not
important, at the moment.
The one thing we should decide *quickly* is if we want to revert
libssl-dev back to 1.0, or if we want to delay the freeze by several
months.
> By letting libssl-dev provide libssl1.0 we do not open this door, and we let
> maintainers decide on a per-basis case.
Yes, and we avoid cases like with libcurl3, where the recompile to
libssl1.1 broke ABI compatibility of libcurl3 without notice.
Jan
Reply to: