Hi Lukas,

On Mon, Oct 18, 2021 at 04:47:12PM +0200, Lukas Tribus wrote:
> Hello,
> 
> PCRE (1) is end of life and unmaintained now (see below).

Thanks for bringing this!

> Not a huge
> problem, because PCRE2 has been supported since haproxy 1.8.
> 
> However going forward (haproxy 2.5+) should we:
> 
> - warn when compiling with PCRE?
> - remove PCRE support?
> - both, but start with a warning in 2.5?
> - maintain PCRE support as is?

I think we should proceed like we're doing with older SSL versions,
which is, as long as they still work, let's keep them, as they are
useful to some users who need to install haproxy on an existing
machine to work around an interoperability issue. Since PCRE is easy
to detect at build time, we could possibly emit a warning from the
makefile itself to remind that it reached end of support. But it's
been found on a large number of systems and I honestly don't know the
status of PCRE2 in all software that used to adopt PCRE a decade ago.
For example a patch to support pcre2 was proposed to Exim just a month
ago. Last I checked (~a year ago) NGINX also didn't support pcre2. Thus
we can be sure to still find PCRE widely deployed on many systems.

> from the main PCRE author at:
> https://github.com/PhilipHazel/pcre2/issues/26#issuecomment-944916343
> 
> > For 6 years after the release of PCRE2 we continued to maintain PCRE1
> > before declaring End-of-Life. There will never be another release. If people
> > want to continue to use the legacy version, that's fine, of course, but they
> > must arrange their own maintenance. I would venture to suggest that the
> > amount of effort needed to do any maintenance is probably less that
> > what is needed to convert to PCRE2. A number of issues that caused
> > problems in PCRE1 have already been addressed in PCRE2.
> >
> > I am sorry to have to sound harsh here, but the maintainers are just
> > volunteers with only so much time for this work, and furthermore, after
> > nearly 7 years I for one have forgotten how the PCRE1 code works. I
> > am therefore going to close this issue "invalid" and "wontfix".

I think that Phil is very reasonable here. From my experience of
maintaining old stuff, I know that there's a point where a maintainer
becomes incompetent on too old code and the quality degrades again
when backporting fixes that start to break other things. If he doesn't
know that code anymore he should indeed stop, and if others need it so
much, someone else will step up.

Cheers,
Willy

Reply via email to