On Mon, Nov 14, 2016 at 08:44:35AM +0100, Ondřej Surý wrote:
> On Mon, Nov 14, 2016, at 08:21, Adrian Bunk wrote:
> > On Mon, Nov 14, 2016 at 05:03:45AM +0100, Ondřej Surý wrote:
> > > > Looking at mod_ssl_openssl.h and the comment in #828330,
> > > > I'd suggest the change below to add a dependency on libssl1.0-dev
> > > > to apache2-dev.
> > >
> > > And that exactly happens meaning that PHP 7.0 can no longer be built
> > > unless all it's build-depends (including PHP 7.0) and rdepends move to
> > > libssl1.0-dev as well.
> > >
> > > So a nice deadlock, right? To be honest I would rather have a slightly
> > > less tested apache2 with OpenSSL 1.1.0 and iron out the bugs as we go
> > > than revert all the work I have done.
> > >
> > > I reviewed the patch Kurt has provided and I don't see any strong reason
> > > why anything should break.
> > >...
> >
> > Can you guarantee that rdeps of Apache can use 1.0.2 in stretch when
> > Apache itself uses 1.1?
>
> Why?
How do you fix rdeps of Apache that are not compiling or working
stable with 1.1?
We are already inside the stretch freeze.
Many packages are not even compiling with 1.1
And run-time testing with 1.1 has not even begun for most packages.
Did you confirm that the Apache code you reviewed actually works
flawlessly? Runtime bugs like #843988 are possible.
> > That is the most important question here.
>
> No, I think the question is:
>
> Can we migrate (or drop) all rdeps to 1.0.2?
The answer is "yes, we can migrate all".
All OpenSSL-using packages in unstable were compiled with and using
1.0.2 until libssl-dev switched from 1.0.2 to 1.1 just 2 weeks ago.
Even today 80% of all libssl dependencies in unstable are still
against libssl1.0.2 (1.1 binNMUs have not yet been done).
> > This is what my "mod_ssl_openssl.h and the comment in #828330"
> > was referring to.
> >
> > The dual 1.0.2/1.1 setup for stretch can only work when any set of
> > packages in the archive that needs the same OpenSSL version stays
> > at 1.0.2 unless *all* packages in this set are compiling and working
> > fine with 1.1
>
> The *set* you are talking probably cover whole archive, since the
> Build-Depends of PHP are quite vast and here are the Build-Depends
> of Build-Depends:
>
> (This is from stretch, not from unstable)
> apache2-dev libssl-dev (>= 0.9.8m)
> libc-client2007e-dev libssl-dev
> libcurl4-openssl-dev libssl-dev
> libevent-dev libssl-dev
> libkrb5-dev libssl-dev
> libpq-dev libssl-dev
> libsasl2-dev libssl-dev
> libsnmp-dev libssl-dev (>> 0.9.8)
>
> Greping just Depends: on -dev packages is slightly more optimistic:
>
> apache2-dev libssl-dev (<< 1.1)
> libc-client2007e-dev libssl-dev
> libpq-dev libssl-dev
> libsnmp-dev libssl-dev
>
> But ultimately I am afraid that libssl dependencies are so entagled
> that it will cover all archive.
"all archive" is not correct, but more packages in stretch using
1.0.2 than 1.1 sounds realistic.
> > And since the OpenSSL version used is part of the libcurl3 ABI
> > (see #844018 for details), using 1.1 in stretch is anyway not
> > really an option for Apache/PHP in stretch.
>
> What you are really saying is that using OpenSSL 1.1 is generally
> not an option for stretch.
It is not a realistic option for larger groups of packages that have to
use the same OpenSSL version.
It was clear before the OpenSSL default changed that using only 1.1 in
stretch would not be realistic.
It was known before the OpenSSL default changed that problems like with
libcurl3 could happen.
Considering that we are already in the freeze, for any OpenSSL 1.1
related problem without a simple and fast solution the only option
within the stretch release schedule is to move packages back to 1.0.2
> Cheers,
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
