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

On Sat, Jan 14, 2023 at 10:59:18PM -0800, Junio C Hamano wrote:

Jeff King [off-list ref] writes:

quoted

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=...".

I'm pretty strongly against that solution for anything long-term. Having
to see those warnings is not only ugly, but it's confusing and trains
people to ignore them (and many times I've noticed ugly warnings
floating by and realized that oops, I had temporarily disabled -Werror
because I had been working with some older code).

quoted

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.

True.

I do think the IOCTL/SEEK one is old enough that we can do, though. The
deprecation is newer, but the SEEK interface was added in an old enough
version.

-Peff