[RFC] PCRE2 migration View as Markdown

Hi Anatol!

-----Original Message-----
From: Christoph M. Becker [mailto:cmbecker69@gmx.de]
Sent: Monday, October 23, 2017 4:24 PM
To: Anatol Belski ab@php.net; internals@lists.php.net
Subject: Re: [RFC] PCRE2 migration

In my opinion, the only real issue is that the internal API would change (the few
userland affecting changes appear to be acceptable). I can't assess how many
extensions actually use the public API of ext/pcre, but this might be an issue
regarding the adoption of PHP 7.3.

Some exts use PCRE or the PHP API, of course. From what I've seen so far

• The migration is easy, despite the PCRE2 API is somewhat different. If asked, I could help patching any code for PCRE2 support.
• there's time to rework the API as in the patch, some points can be changed significantly
• From what I could tell, the ratio of PECL exts using PCRE is low. In fact, I can't remember any, OFC there are be some.

Well, that sounds good. :) And yes, I'm aware that upgrading to PCRE2
is actually long overdue, so +1 from me.

--
Christoph M. Becker

Hi Jakub,

-----Original Message-----
From: jakub.php@gmail.com [mailto:jakub.php@gmail.com] On Behalf Of
Jakub
Zelenka
Sent: Monday, October 23, 2017 10:43 PM
To: Anatol Belski ab@php.net
Cc: internals@lists.php.net
Subject: Re: [PHP-DEV] [RFC] PCRE2 migration

Hey

On Mon, Oct 16, 2017 at 9:17 AM, Anatol Belski <ab@php.net
mailto:ab@php.net > wrote:

  Hi,

  I would like hereby to put the RFC about the PCRE2 migration for

the

  core https://wiki.php.net/rfc/pcre2-migration

https://wiki.php.net/rfc/pcre2-migration under discussion. A basic
port is available here https://github.com/php/php-src/pull/2857
https://github.com/php/php-src/pull/2857 for a
review.

Sorry if that's a stupid question and I'm missing something important
but why do
we need to still bundle PCRE2?

I ask such questions just for the fun of it all the time, that makes sense
to my character ?

The point of the RFC is the max BC. Currently PCRE is bundled. Otherwise,
the lib is essential for the core and thus needs to be always available.
For older distro versions like for example Debian Jessie or other OSes not
yet providing PCRE2 from the package management, that would be the only way
to get a newer PHP version, even if compiled by hand. Except maybe when
libpcre2 were provided by a third party repo, or a PPA in the Debian
terminology.

Another point on that is, even if a package is available on the target
platform - the bundled version is what is tested and highly recommended.
Builders can decide otherwise, but what we provide makes the point. Lately,
for example - the valgrind support is also essential, as a release version
supplied by a distro likely wouldn't be built with valgrind support but
it's required to debug PHP issues.

Otherwise, there's no need for bundling. This dependency is currently not
patched in the way it would be the only one to be required bundled. It is
simply handy to have it bundled for the development and compatibility. Any
distribution can decide, whether they would use it bundled or external.

Well I think that all listed reasons for bundling could be applied to other
libraries. For example we won't start bundling OpenSSL just because we
won't to make the new functionality easily available. The debugging point
can be also true there because distros won't ship version configured with
-d. However one can easily compile the library in that way so I don't see
it as a problem at all. Personally I'm not a big fan of bundling libraries
unless there is some technical reason to do so (for example an unexposed
API that is necessary for inner working of the extension). The number of
PCRE2 releases and its size is of course much smaller than for example
mentioned OpenSSL but it still seems a bit unnecessary to me.

Anyway this is something that can be discussed separately as we already
bundle PCRE so this is just a bundle replacement that actually reduces the
number of bundled lines... :)

Cheers

Jakub