Re: [RFC] dropping support for ancient versions of curl

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Apr 5, 2017, 10:51 UTC
Message-ID: <CACBZZX450tRRsy-Sj8igZthYov7UxFMRJ51M-b1cgYBLo782jQ@mail.gmail.com>
In-Reply-To: <d6ba17f0-3da9-8699-8d5c-5ebf1eaef00e@jupiterrise.com>

On Wed, Apr 5, 2017 at 11:33 AM, Tom G. Christensen <tgc@jupiterrise.com> wrote:

Show 27 quoted lines

> On 04/04/17 04:54, Jeff King wrote:
>>
>> A nearby thread raised the question of whether we can rely on a version
>> of libcurl that contains a particular feature. The version in question
>> is curl 7.11.1, which came out in March 2004.
>>
>> My feeling is that this is old enough to stop caring about. Which means
>> we can drop some of the #ifdefs that clutter the HTTP code (and there's
>> a patch at the end of this mail dropping support for everything older
>> than 7.11.1). But that made wonder: how old is too old? I think it's
>> nice that we don't force people to upgrade to the latest version of
>> curl. But at some point, if you are running a 13-year-old version of
>> libcurl, how likely are you to run a brand new version of Git? :)
>>
>
> FWIW I maintain freely available updated git packages for RHEL 3, 4, 5, 6
> and 7.
>
> They can be found here:
> https://jupiterrise.com/blog/jrpms/
>
> And direct access here:
> https://jupiterrise.com/jrpms/ (for el3,el4,el5)
> https://jupiterrise.com/jrpmsplus/ (for el6, el7)
>
> They are built against system versions of curl though a few patches are
> required for 7.10.6 (el3) and 7.12.1 (el4) support.

Whoah. So my assumption in <CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com> that nobody was compiling this & thus not reporting failures was false. Rather there's an entire community & distribution mechanism around patching git for older EL versions, but the patches aren't making it upstream.

$ grep -h -e ^Subject -e ^Date *patch
Date: Tue, 13 Oct 2009 11:34:11 +0200
Subject: [PATCH 1/7] Make NO_PERL_MAKEMAKER behave more like
Date: Fri, 13 Jun 2014 11:02:02 +0200
Subject: [PATCH 2/7] Install man pages when NO_PERL_MAKEMAKER is used
Date: Mon, 22 Sep 2014 13:42:50 +0200
Subject: [PATCH 3/7] Allow svnrdump_sim.py to be used with Python 2.2
Date: Tue, 8 Mar 2016 09:31:56 +0100
Subject: [PATCH 4/7] Handle missing HTTP_CONNECTCODE in curl < 7.10.7
Date: Tue, 23 Aug 2016 10:32:51 +0200
Subject: [PATCH 5/7] Add support for gnupg < 1.4
Date: Tue, 23 Aug 2016 18:15:13 +0200
Subject: [PATCH 6/7] Handle missing CURLINFO_SSL_DATA_{IN,OUT}
Date: Tue, 23 Aug 2016 18:26:54 +0200
Subject: [PATCH 7/7] Do not use curl_easy_strerror with curl < 7.12.0
Date: Wed, 2 Feb 2011 21:24:44 -0500
Subject: [PATCH] Restore vc-git.el for basic compatibility on EL-5
Date: Mon, 23 Mar 2009 00:03:36 -0400
Subject: [PATCH] git-cvsimport: Ignore cvsps-2.2b1 Branches: output

Show 5 quoted lines

> Patches can be found in the src.rpm, though I can also post them here as
> patch series, they cover more than just curl.
>
> I don't use the el3 and el4 versions much any more and el5 use will also
> drop of now as I'm busy converting machines from el5 to el7.

It would be great to have them on-list, as far as I can tell they were never submitted? Is there some time/administrative reason for why you're not submitting them? Some of these are many years old, it would be great to have them on-list for wider review & included so vanilla git works on these platforms.