Andreas: No, it’s not a bug. PCRE2 is a new project that’s not intended to be compatible with the older PCRE (i.e. what Debian misnamed “pcre3”). The API is completely different and this is expected. See bug 1636666 for context, and specifically the PCRE2 release announcement linked in the bug description:
That’s why getting rid of PCRE “in favor of” PCRE2 is a pointless way to frame the issue. PCRE2 neither replaces nor conflicts with PCRE, as was pointed out many times in bug 1636666.
But since we’re apparently gathering information here: although Apache 2.4.x does not support PCRE2, Apache trunk does support PCRE2 as of r1773454. (As you can see, this support was added by creating separate conditionally compiled code paths for PCRE and PCRE2.)
Andreas: No, it’s not a bug. PCRE2 is a new project that’s not intended to be compatible with the older PCRE (i.e. what Debian misnamed “pcre3”). The API is completely different and this is expected. See bug 1636666 for context, and specifically the PCRE2 release announcement linked in the bug description:
https:/ /lists. exim.org/ lurker/ message/ 20150105. 162835. 0666407a. en.html
That’s why getting rid of PCRE “in favor of” PCRE2 is a pointless way to frame the issue. PCRE2 neither replaces nor conflicts with PCRE, as was pointed out many times in bug 1636666.
But since we’re apparently gathering information here: although Apache 2.4.x does not support PCRE2, Apache trunk does support PCRE2 as of r1773454. (As you can see, this support was added by creating separate conditionally compiled code paths for PCRE and PCRE2.)
https:/ /github. com/apache/ httpd/commit/ b1a3338e011a17a d190fb7f66cf5ca 9acf353570