Re: [PATCH] http: support building on RHEL6

["Ævar Arnfjörð Bjarmason" <avarab@gmail.com>]

On Fri, Jul 01 2022, Junio C Hamano wrote:

> Junio C Hamano <gitster@pobox.com> writes:
>
>> But I do not think the patch text, what the patch does, is that bad.
>> We advertise in INSTALL that you need 7.19.4 to build without NO_CURL;
>
>> IOW, you should be able to build Git with 7.21.3 or later.
>
> That conclusion is nonsense.  "with a version before 7.21.3 as long
> as it is newer than 7.19.4" is what I should have said.

I find this line of argument to be circular legalese without a
distinction.

As 644de29e220 (http: drop support for curl < 7.19.4, 2021-07-30) notes
(which I submitted as part of the git-curl-compat.h series) the reason
we have 7.19.4 as a cut-off is entirely due to RHEL.

So, if you do agree with brian that supporting RHEL6 is a bad idea
supporting RHEL6 v.s. supporting libcurl 7.19.4 is a distinction without
a difference.

There's also a 7.19.3, and a 7.19.5, we didn't pick specifically 7.19.4
by accident.

Yes you *could* run Linux-From-Scratch and just so happen to have that
version, but in reality practice almost everyone who cares about 7.19.4
does so because the cut-off is synonymous with RHEL6 and its
derivatives. The same goes for other "magic versions" shipped by later
major OS versions from various vendors.

Brian & I have disagreed on the larger point in the past, not to re-hash
the entire thing here (which can be found in some libcurl threads in
particular, and other "older OS" threads), but somewhat briefly:

 * I think we should be more aggressive in bumping required dependency
   versions, but not as a stick to force users on older systems to
   upgrade out of some enforcement of the Greater Good.

   But simply because we should weigh our time & effort in supporting
   and testing older versions, v.s. the relatively small effort for
   packager to build a newer git *and* its updated dependencies[1].

 * Having said that I entirely disagree with the premise that we should
   view the consumers of our software on free software platforms as
   helpless users who can't make an informed decision about whether they
   should run on older OS with newer software.

   Whether something is supported by upstream is only one factor in
   evaluating the security of a given installation, and whether security
   even really matters in that case (some older RHEL installs are
   firewalled off, or one some private network etc.).

   It's one thing to demand that we do their work for them (which per
   the above, I think it's fair to ask them to do more work). But
   arguing from the *principle* that we use non-support for older
   systems as a wedge quickly leads to justifying actively breaking
   older OS's, or not taking portability patches where the maintenance
   burden is trivial.

 * I really don't care that much about older libcurl in particular
   (using NO_CURL=Y or compiling it yourself is easy).

   But the reason some of us use or test on older OS's is not because we
   think exposing Solaris 10 (released in 2005, see [2]) or whatever to
   the wider internet would be a good idea, but because those older OS's
   tend to find edge cases is our portability assumptions, which
   sometimes even helps portability on newer or future OSs.

The reason I wrote the above now is because I'd really not like
e.g. future C portability patches or whatever that are easy to carry but
happen to cater to some "EOL" OS to be rejected out of hand because
"there's no possible way that any Git developer can be expected to
support [it]", and to have this thread cited as justification without
there being a dissenting argument to be found.

Even if I agreed with the goals I think the argument is still
fundamentally flawed. Some vendors of older OS's don't publish the same
sort of deprecation and support time tables that Red Hat does, even
though their older (and sometimes newer) OS's are probably more insecure
in practice.

Therefore if our criteria for shunning an OS is that its vendor deems it
insecure, we're not only using our clout to encourage them to upgrade,
but also encouraging the use of OS's whose vendors aren't themselves as
strict about encouraging users to upgrade.

1. https://lore.kernel.org/git/CACBZZX78oKU5HuBEqb9qLy7--wcwhC_mW6x7Q+tB4suxohSCsQ@mail.gmail.com/
2. https://cfarm.tetaneutral.net/machines/list/