On July 23, 2021 12:21 PM, Junio C Hamano wrote: >Jeff King <peff@xxxxxxxx> writes: > >> On Thu, Jul 22, 2021 at 12:22:11AM +0200, Ævar Arnfjörð Bjarmason wrote: >> >>> This series is a re-roll of patches found in Peff's GitHub repo at >>> jk/no-ancient-curl, which were already-rebased versions of those >>> patches. His original on-list version had his Signed-off-by, but the >>> range-diff is against that branch, hence the addition of >>> Signed-off-by in the range-diff. >> >> Heh, OK. It's a little surprising to see random junk pulled out of my >> GitHub repo, but in this case I was holding onto them with the intent >> of eventually resending after more time passed. >> >> So I'm happy to see these cleaned up and posted. I think what's on >> that branch should be good-ish, in the sense that I've been rebasing >> it forward as part of my daily routine, and it's part of the build >> that I use day-to-day. Though apparently I never applied the >> CURLOPT_POST301 fix. :-/ > >Thanks. > >> I know my S-o-b was on the originals to the list, but just to make >> clear: I am fine with using them on the rebased versions you grabbed. > >Good. S-o-b is merely "I can let the project use it" and does not say "I agree this is (still) relevant in the context of the code this is being >submitted to", so the above note is very much appreciated. > >> So modulo the commit message tweaks that Junio suggested, this all >> looks fine. I actually think my original "#error on too-old curl" is >> still reasonable. Yes, people whose distro has backported all of these >> features could possibly still use it. But in that case they likely >> know what's going on and can rip out the #error. It seems much more >> likely to me that it _won't_ work, and they'll get confused by obscure >> errors when they try to use an old curl. >> >> But I don't feel too stronlgy about it either way. > >Me neither. Those who are vanilla would not be helped by having it, as their build would fail if their cURL is too old anyway even without >it. Those who backported would have a build that may or may not work, but diagnosing it is part of the job of backporting their cURL >anyway. So in practice, I think "#error if you are older than X" primarily would serve documentation purposes (which may be worth doing, >but requirements listed in INSTALL would probably be a better alternative anyway). This is probably a red-herring, but from what I am observing, the curl 7.70 version is required for OpenSSL 3.0.0. Once we move there, which my team is working on, the near recent older version of curl could also be problematic and incompatible. This is rather unpleasant because the current standard libcurl on our platform is 7.65, which is too old to be compatible anyway, so we're going to have to put out a separate libcurl build. Curl seems to need to be closer to the bleeding edge to retain imminent compatibility. -Randall
