On Tue, Apr 4, 2017 at 1:54 PM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote: > Hi, > > On Tue, 4 Apr 2017, Ævar Arnfjörð Bjarmason wrote: > >> I think it's completely fine to include your patch as-is. At some >> point we need to pass the burden of dealing with these old software >> versions, saying that you should use a <10 year old library isn't >> unreasonable. Anyone packaging new git on RHEL5 or derivatives can >> just package a newer libcurl as well. > > But how much maintenance burden is it, really? Is the continued use of > those #ifdef's really worth this much discussion, let alone applying a > patch that may break users who have so far been happy? > > It would be a different thing if we had to have hacks to support old cURL > versions, where we need to ship entire >10kB source files that tap into > internal data structures that may, or may not have changed. Such a hack, I > would be happy to discuss when we could possibly remove it. > > But a couple of #ifdef's? C'mon, man, we can carry this *without sweat* > indefinitely ;-) I don't really care about applying this patch, but I wouldn't mind seeing it applied. I just wanted to clarify the counteractive point that it's not unusual for some (particularly corporate) environments to be compiling fresh upstream releases of some software against really ancient versions of other upstream libraries. But as Frank Gevaerts's reply (thanks!) which came after your reply points out, this code has already been broken since v2.12.0, so it's rarely used enough that nobody's reported being unable to compile git 2.12.0 on e.g. CentOS 5 >2 months since release. I think this is a stronger argument for removing stuff like this. At some point we're shipping code nobody's tested in combination with the rest of our code. This can easily becomes a source of bugs as someone e.g. compiling a new git on co5 becomes literally the first person to ever test some new combination of codepaths we've added around mostly unused ifdefs.