Re: [PATCH 0/2] Restore support for older libcurl and fix some typos

From: Torsten Bögershausen <tboegi@web.de>
Date: Oct 17, 2024, 06:59 UTC
Message-ID: <20241017065936.GA16141@tb-raspi4>
In-Reply-To: <CAPig+cRENnd9cV5yFfVVwbuux84k10_vcht-TTtKGJmRNYEttA@mail.gmail.com>

On Tue, Oct 15, 2024 at 02:29:33AM -0400, Eric Sunshine wrote:

Show 29 quoted lines

> On Mon, Oct 14, 2024 at 8:51 PM Alejandro R. Sedeño <asedeno@mit.edu> wrote:
> > On Mon, Oct 14, 2024 at 8:28 PM Taylor Blau <me@ttaylorr.com> wrote:
> > > On Mon, Oct 14, 2024 at 09:13:44AM -0400, Alejandro R. Sedeño wrote:
> > > > This is presented as an alternative to the patch series from
> > > > brian m. carlson that bumps the minimum version of libcurl
> > > > to 7.61.0 [3].
> > >
> > > This conflicts with brian's series as you mention, so I haven't picked
> > > this one up in 'seen' yet.
> > >
> > > Could you summarize why you think this series is a better approach than
> > > what brian has posted? On its own, I do not understand the motivation.
> >
> > It's a question of preserving compatibility vs ratcheting up minimum
> > requirements. Both have their merits. I sent in this patch set after
> > seeing some mild pushback to brian's series, just to present an
> > alternative. Maintaining compatibility with older versions can be a
> > burden to the project, though I think given this patch series, it's
> > not a very big one. Ratcheting up the minimum requirements can be a
> > burden to users stuck on (or choosing to try and support) older
> > platforms. At some point the burden on the project outweighs the
> > desire to support those older platforms. Where that tipping point is
> > is for the community to decide.
>
> For reference, I'm the one who pushed back on brian's series. The
> "push-back" subthread starts at [1].
>
> [1]: https://lore.kernel.org/git/20241014132856.3558224-1-asedeno@mit.edu/T/#mc1180f00cf52de4e9bae334c2cd5abd9a160dbbe
>

Being one of the people who has to work with older distributions, I think that I would support the pushback.

There are many machines out there, which are still running in production with old installations. In my case it is a Centos 7 machine, coming with Git 1.8.3.1

Out of my head, git submodules didn't work (as good as today), and even things like git -P didn't exist then.

I may be worth to mention that this machines are protected by double or triple firewalls, routing tables, and whatever is needed to protect them. Maintaining production software and hardware, systems using specialized hardware with Linux drivers dependend on the Linux kernel is daily work.

And here tools like Git are needed (and appreciated).

My view is that the new developments can focus on the "latest" distributions, and if some comes along and has a patch that make Git compile and work under an older system, and that patch does not break newer systems, it would be a good thing to accept.

The seen branch from October 11 does not compile (any more) under Centos 7. One problem is the curl stuff. And then some warning, missing a prototype for lstat() in clar.c/fs_copy(). And warnings about missing braces around initializers, nothing to worry about.

Lets try a summarize: I can volunteer to compile Git from seen on this Centos box, lets say once a week, and report breakages.

Other toughts ?