Re: [PATCH] ci: do not die on deprecated-declarations warning

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> On the other hand, I don't know how useful those deprecations are going
> to be, as it depends on the timeframe. If the deprecation is added for
> the same version of libcurl that implements the alternative (which is
> roughly the case here), then we'd always be stuck supporting the old and
> new forms (old for backwards compatibility, and new to silence the
> deprecation warning).

... or just keep the warning without promoting, with "-Wno-error=...".

> We care a lot more about the deprecation once the
> alternative has been around for a while, and/or the old way of doing
> things is about to be removed. And if we just wait until that removal,
> then we do not have to rely on deprecation warnings. The build will
> break just fine on its own. :)

Yes and no.  It is not always like "this symbol is now known under
this different name", which is trivial to adjust.  I briefly tried
to see how IOCTL -> SEEK change should look like until I realized
that the new way was invented too recently and stopped looking, but
it would involve changes to the function logic in the callback
functions, as the function signature---both parameters and its
return values---of the callback changes.  I do not want to see us
scrambling to make such adjustments to the code at the last minute,
so some sort of advance warning is a good thing to have.

Thanks.