Hi Niels,
On Tue, Jan 10, 2017 at 09:36:57PM +0100, Niels Thykier wrote:
> Package: zurl
> Version: 7.51.0-1
> Severity: grave
> Tags: sid stretch
>
> Hi,
>
> Please use ssl1.0 for stretch.
>
> We have requested the curl also reverts to ssl1.0 (please see
> #850880). Since zurl is using a curl function exposing SSL_CTX, it
> will have to use the same version libssl as curl itself.
This leads to an unfortunate situation:
zurl/1.7.1-2 in testing is _not_ affected by this bug, as it's linked
against openssl 1.0 and also build-depends on libssl1.0-dev.
But still, it's currently broken by curl 7.51.0-1, which went to testing
even tough it should have been blocked by #844018, a bug predicting
exactly this very issue.
zurl/1.7.1-3 would fix that, so it should go ASAP to testing, to
minimize user impact. Without the 10-day-policy, it would already have
entered testing.
Now what shall I do? I understand that the proper solution would be the
one you suggest. But that would add another 10-day-delay, and would only
help in case curl in testing _also_ was updated by then. Which I doubt,
as #844018 is open since 2 months without any action.
IMHO, the best solution for our users would be waiting until
zurl/1.7.1-3 entered testing (fixing the immediate impact), and then
uploading a fixed version zurl/1.7.1-4, which also conflicts with
libcurl3 at version 7.51.0-1. That would make both the fixed version of
curl and zurl move from sid to testing at the same time, making the
update seamless for our users.
Am I missing something? Is this a good way to handle the situation?
Would it be possible to speed up the propagation of zurl/1.7.1-3 to
testing so I can upload zurl/1.7.1-4?
Jan
