On Mon, Oct 23, 2017 at 10:07 PM, Anatol Belski <a...@php.net> wrote:
> Hi Jakub, > > > -----Original Message----- > > From: jakub....@gmail.com [mailto:jakub....@gmail.com] On Behalf Of > Jakub > > Zelenka > > Sent: Monday, October 23, 2017 10:43 PM > > To: Anatol Belski <a...@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 <a...@php.net > > <mailto:a...@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
