Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87749
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain belski.net from 85.214.73.107 cause and error)
To: "'Adam Harvey'" <aharvey@php.net>,
	"'Christoph Becker'" <cmbecker69@gmx.de>
Cc: "'PHP internals'" <internals@lists.php.net>
References: <55CA26DF.3030109@gmx.de> <03dd01d0d476$c75b6730$56123590$@belski.net> <55CA646F.8020506@gmx.de> <040101d0d4ca$656f4e20$304dea60$@belski.net> <55CC80FC.5070306@gmx.de> <CADajX4CcuDJLQtEjcS+-O_Dr9yYerRe4M=hyn1oP_Bggifmp8A@mail.gmail.com>
In-Reply-To: <CADajX4CcuDJLQtEjcS+-O_Dr9yYerRe4M=hyn1oP_Bggifmp8A@mail.gmail.com>
Date: Fri, 14 Aug 2015 01:25:00 +0200
Message-ID: <066a01d0d61f$4937d370$dba77a50$@belski.net>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQH7++SmR5Qqa5F1jGgVRfCNseMOmgMakR6SAY8BXI8BLOfZNwFYh0tDAgjcCuGdaoPlwA==
Content-Language: en-us
Subject: RE: [PHP-DEV] libpcre version requirements
From: anatol.php@belski.net ("Anatol Belski")



> -----Original Message-----
> From: adam@adamharvey.name [mailto:adam@adamharvey.name] On Behalf
> Of Adam Harvey
> Sent: Thursday, August 13, 2015 8:44 PM
> To: Christoph Becker <cmbecker69@gmx.de>
> Cc: Anatol Belski <anatol.php@belski.net>; PHP internals
> <internals@lists.php.net>
> Subject: Re: [PHP-DEV] libpcre version requirements
>=20
> On 13 August 2015 at 04:35, Christoph Becker <cmbecker69@gmx.de> =
wrote:
> > On 12.08.2015 at 08:44, Anatol Belski wrote:
> >>
> >> [...] However look - =
http://w3techs.com/technologies/details/os-linux/all/all
> . From those, CentOS 5/6 releases are not even a year old and contain =
6.6, 7.x
> but take 20% of all the Linux market share. Note that according to =
that Linux
> takes only 35.9% of it. Now, say disregarding CentOS 5 and other =
rare/too old
> platforms, the other 65% of the usages are not taken into account. So =
how
> much loss on PHP7 adoption would happen, is a question. Maybe there =
are other
> stats, just operating on what is available.
> >>
> >> On the other hand  - as with the bug #70232, is it really worth =
disabling the
> whole PCRE just to be sure one bug is fixed? I would see it as not =
being such.  It
> is clear, that no distro will suddenly be upgrading from say PHP 5.3 =
to PHP7 in an
> older branch, but keeping as much compat as possible will allow third =
party
> repositories to still provide PHP7 there. This is at least my reason =
to say the
> version shouldn't be raised - as it shouldn't go beyond 7.x at least =
because of
> CentOS 6, and then it is probably useless to do it ATM. As long as it =
doesn't block
> the work towards future, at least.
> >
> > Well, then it might be best to leave the requirements as they are =
for
> > now. :)
>=20
> I'm still OK requiring 8.00 in PHP 7.0, personally =E2=80=94 even that =
is almost six years
> old, and users on older distros and OSes can use the bundled libpcre. =
It's not like
> this is going to break the common case where the user doesn't set any =
specific
> PCRE flags in configure, and I don't think it's unreasonable to expect =
third party
> packagers to use a bundled library if they're building on that old a =
system.
> They're effectively shouldering the burden of providing security =
updates for PHP
> regardless of what the distro does.

What about the other 65% of the market share where we have no idea what =
happens? Well, some of them are Windows where bundled PCRE is used, but =
the rest is like UNIXes, maybe they're 50/50 or alike.

Besides that - an average user won't even have gcc installed to use the =
bundled PCRE or not, and what packagers would do - yep, that's a =
question. However distributions usually enforce shared libs usage for =
the exact reason to centralize delivery of the (security) updates.

I would suggest to make this move (raising the PCRE version to 7 or 8) =
in master after 7.0 is branched. Then there were enough time to see how =
7.0 is being handled, to get feedback on that change and to react =
accordingly, if needed.

Regards

Anatol