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