Re: [PATCH 00/13] Update versions of libcurl and Perl
- From
Alejandro R. Sedeño <asedeno@mit.edu>
- Date
- Oct 11, 2024, 19:08 UTC
- Message-ID
- <20241011190812.2654837-1-asedeno@mit.edu>
- In-Reply-To
- <xmqqttdicws8.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
Show 19 quoted lines
> Eric Sunshine <sunshine@sunshineco.com> writes: > > > I may be in the minority here, but I'm fairly negative on this entire > > patch series. As you say, supporting these old versions is effectively > > zero-cost, so how does this project benefit from these changes which > > potentially "break" Git for users on older platforms? I see no upside > > here. The cover letter provides no strong justification for > > (potentially) inconveniencing people; the argument about being able to > > utilize more modern Perl features is weak[1] at best and is not > > convincing. > > While I agree with all you said above, one thing I find missing is > that even with #ifdef, we won't be shipping what we tested in real, > as nobody, not just the author that touches the same file with the > #ifdef we added 6 months ago is in, but all other developers who > looked at the change. It merely is "we have #ifdef here and those > with ancient version of the library shouldn't see this new code", > which certainly is good enough for those of us who consider the > ancient platform support as a "best effort" thing.
Should I go ahead and send the patch series that I had planned to fix the breakage for old libcurl after all? I've gone ahead and built the latest version for one of the ancient platforms I inexplicably build git for, but am now dealing with breakage on another (SunOS 5.10).
(Specifically, the new unit test framework stuff was failing to generate a suite file, patch forthcoming, and depends on mkdtemp, which we check for in configure but use unconditionally in the newly-imported clar, and which I don't have here.)
-Alejandro