Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » Bundled libraries upgrade 'process' »

Bundled libraries upgrade 'process'

php.internals

Dan Ackroyd

9 years ago
Hi Internals, I just investigated an alleged bug related to the SQLite3 extension. It seems this bug occurs when PHP is compiled with the current bundled SQLite files, which are a little out of date as they are version: "3.15.1", date: "2016-11-04". Listed at https://sqlite.org/changes.html there are multiple versions that SQLite could be upgraded to. * 2016-11-28 (3.15.2) - small bugfix upgrade. * 2017-06-08 (3.19.3) - bigger upgrade that has performance improvements. Questions: 1. Do we have a process for deciding whether to upgrade bundled libraries? 2. Can anyone see anything in the release notes that would be a problem for upgrading past 3.15.2 ? 3. Do we have a process for getting feedback from users about whether a proposed upgrade would cause problems, other than doing the upgrade and shipping it? I can't see anything listed in the SQLite release notes that would cause a problem.....but that's obviously not the same as being sure an upgrade wouldn't cause problems. cheers Dan Ack

Ryan Jentzsch

9 years ago
This may be a dumb question...I was under the impression that including the config switches for the databases such as MySQL, SQLite, Postgres, etc. that ONLY the PDO bindings are included NOT the database client itself. Is this the case with the exception of SQLite? In other words is the version of MySQL that is bundled with PHP also built when I build from source? Or am I misunderstanding this whole issue? - Ryan On Mon, Jul 17, 2017 at 8:12 AM, Dan Ackroyd <danack@basereality.com> wrote:

lists@rhsoft.net

9 years ago
Am 17.07.2017 um 18:04 schrieb Ryan Jentzsch:
> This may be a dumb question...I was under the impression that including the > config switches for the databases such as MySQL, SQLite, Postgres, etc. > that ONLY the PDO bindings are included NOT the database client itself. > > Is this the case with the exception of SQLite? In other words is the > version of MySQL that is bundled with PHP also built when I build from > source? Or am I misunderstanding this whole issue?
you need to distinct bewteen "--with-feature" and "--with-fedora=/usr" and a sane build normally avoids bundeling as much as possible with "mysqlnd" you have "libmysqlclient" not in the mix at all for years # configure build process ./configure \ --host=x86_64-redhat-linux \ --build=x86_64-redhat-linux \ --target=x86_64-redhat-linux \ --prefix=%{_prefix} \ --program-prefix= \ --libdir=%{_libdir}/%{name} \ --disable-all \ --disable-dependency-tracking \ --enable-bcmath=shared \ --enable-calendar=shared \ --enable-cli \ --enable-ctype=shared \ --enable-dom=shared \ --enable-exif=shared \ --enable-fileinfo=shared \ --enable-filter \ --enable-hash=shared \ --enable-huge-code-pages \ --enable-inline-optimization \ --enable-intl=shared \ --enable-json=shared \ --enable-libxml \ --enable-mbregex \ --enable-mbstring=shared \ --enable-mysqlnd=shared \ --enable-opcache=shared \ --enable-opcache-jit \ --enable-pcntl=shared \ --enable-pdo=shared \ --enable-phar=shared \ --enable-posix=shared \ --enable-re2c-cgoto \ --enable-session=shared \ --enable-shared \ --enable-simplexml=shared \ --enable-soap=shared \ --enable-sockets=shared \ --enable-tokenizer=shared \ --enable-xml=shared \ --enable-xmlreader=shared \ --enable-xmlwriter=shared \ --enable-zip=shared \ --with-apxs2=%{_bindir}/apxs \ --with-bz2=shared,%{_prefix} \ --with-config-file-path=%{_sysconfdir} \ --with-config-file-scan-dir=%{_sysconfdir}/%{name}.lounge.d \ --with-curl=shared,%{_prefix} \ --with-freetype-dir=%{_prefix} \ --with-gd=shared,%{_prefix} \ --with-gettext=shared,%{_prefix} \ --with-iconv=shared \ --with-imap-ssl=%{_prefix} \ --with-imap=shared,%{_prefix} \ --with-kerberos=%{_prefix} \ --with-layout=GNU \ --with-libdir=%{_lib} \ --with-libedit=shared,%{_prefix} \ --with-libxml-dir=%{_prefix} \ --with-libzip=%{_prefix} \ --with-mysql-sock=%{_sharedstatedir}/mysql/mysql.sock \ --with-mysqli=shared,mysqlnd \ --with-openssl=shared,%{_prefix} \ --with-pcre-jit \ --with-pcre-regex=%{_prefix} \ --with-pdo-mysql=shared,mysqlnd \ --with-pic \ --with-system-ciphers \ --with-system-tzdata \ --with-tidy=shared,%{_prefix} \ --with-zlib=shared \ --with-zlib-dir=%{_prefix} \ --disable-cgi \ --disable-dmalloc \ --disable-dtrace \ --disable-gcov \ --disable-gd-jis-conv \ --disable-ipv6 \ --disable-mysqlnd-compression-support \ --disable-opcache-file \ --disable-phpdbg \ --disable-rpath \ --disable-short-tags \ --disable-static \ --%{RH_LTO_CONFIGURE_OPTION} \ --%{RH_CONFIGURE_DEBUG_OPTION

Christoph Becker

9 years ago
On 17.07.2017 at 16:12, Dan Ackroyd wrote:
> I just investigated an alleged bug related to the SQLite3 extension.
Can you please report the bug and assign it to me. I can't promise that I'll be able to fix it, but I would take a look.
> It seems this bug occurs when PHP is compiled with the current bundled > SQLite files, which are a little out of date as they are version: > "3.15.1", date: "2016-11-04". > > Listed at https://sqlite.org/changes.html there are multiple versions > that SQLite could be upgraded to. > > * 2016-11-28 (3.15.2) - small bugfix upgrade. > * 2017-06-08 (3.19.3) - bigger upgrade that has performance improvements. > > Questions: > > 1. Do we have a process for deciding whether to upgrade bundled libraries?
Nothing strict. Since several months I'm keeping master and pre-release branches up to date with current SQLite3 releases. I do not touch GA branches, because that could do more harm than good. If there is a known bug that affects PHP, I suggest to update only as necessary, i.e. in this case to 3.15.2, and even this should probably be discussed with the respective release manager(s). Note, that I assume that the bundled libsqlite3 is most likely used on Windows only, anyway, because Linux distros usually roll out their own.
-- Christoph M. Becker

Dan Ackroyd

9 years ago
On 17 July 2017 at 20:09, Christoph M. Becker <cmbecker69@gmx.de> wrote:
> On 17.07.2017 at 16:12, Dan Ackroyd wrote: > >> I just investigated an alleged bug related to the SQLite3 extension. > > Can you please report the bug and assign it to me. I can't promise that > I'll be able to fix it, but I would take a look. >
It's already been reported and fixed upstream. Reported 'bug': https://bugs.php.net/bug.php?id=74883 Fixed in commit: https://www.sqlite.org/src/info/f27b6370407842e2 So actually, the fix won't be available until we upgrade to 3.20.0, which should be released in 2 days, according to https://www.sqlite.org/draft/releaselog/current.html
>> 1. Do we have a process for deciding whether to upgrade bundled libraries? > > Nothing strict. Since several months I'm keeping master and pre-release > branches up to date with current SQLite3 releases. I do not touch GA
All sounds sensible. cheers Dan Ack

Anatol Belski

9 years ago
Hi,
> -----Original Message----- > From: Dan Ackroyd [mailto:danack@basereality.com] > Sent: Tuesday, July 18, 2017 10:42 AM > To: Christoph M. Becker <cmbecker69@gmx.de> > Cc: internals@lists.php.net > Subject: [PHP-DEV] Re: Bundled libraries upgrade 'process' > > On 17 July 2017 at 20:09, Christoph M. Becker <cmbecker69@gmx.de> wrote: > > On 17.07.2017 at 16:12, Dan Ackroyd wrote: > > > >> I just investigated an alleged bug related to the SQLite3 extension. > > > > Can you please report the bug and assign it to me. I can't promise > > that I'll be able to fix it, but I would take a look. > > > > It's already been reported and fixed upstream. > > Reported 'bug': https://bugs.php.net/bug.php?id=74883 > > Fixed in commit: https://www.sqlite.org/src/info/f27b6370407842e2 >
Thanks for the info. The fix in mainstream doesn't look critical, as the return code is already being caught in PHP. Clear, there are explicit option checks in the linked patch, but the currently bundled Sqlite would bail out anyway. A possible improvement in the end is a different error text. The version jump seems to be big and barely justified, furthermore I'd be hesitant to bundle a just released version. Except there are some other bugs that are fixed by the newer version, I would rather go by applying the patch to the current bundled lib (if possible) or letting it go. Regards Anatol

Christoph Becker

9 years ago
On 18.07.2017 at 12:15, Anatol Belski wrote:
>> -----Original Message----- >> From: Dan Ackroyd [mailto:danack@basereality.com] >> Sent: Tuesday, July 18, 2017 10:42 AM >> To: Christoph M. Becker <cmbecker69@gmx.de> >> Cc: internals@lists.php.net >> Subject: [PHP-DEV] Re: Bundled libraries upgrade 'process' >> >> On 17 July 2017 at 20:09, Christoph M. Becker <cmbecker69@gmx.de> wrote: >>> On 17.07.2017 at 16:12, Dan Ackroyd wrote: >>> >>>> I just investigated an alleged bug related to the SQLite3 extension. >>> >>> Can you please report the bug and assign it to me. I can't promise >>> that I'll be able to fix it, but I would take a look. >> >> It's already been reported and fixed upstream. >> >> Reported 'bug': https://bugs.php.net/bug.php?id=74883 >> >> Fixed in commit: https://www.sqlite.org/src/info/f27b6370407842e2 > > Thanks for the info. The fix in mainstream doesn't look critical, as the return code is already being caught in PHP. Clear, there are explicit option checks in the linked patch, but the currently bundled Sqlite would bail out anyway. A possible improvement in the end is a different error text. The version jump seems to be big and barely justified, furthermore I'd be hesitant to bundle a just released version. Except there are some other bugs that are fixed by the newer version, I would rather go by applying the patch to the current bundled lib (if possible) or letting it go.
I agree that updating all supported PHP versions to Sqlite 3.20.0 isn't justified here, particularly since I think this is a userland application error – why would one create a database in read-only mode? There wouldn't be much to read, and most likely they'd get an error for a following `select`. IMHO it would even be sufficient to integrate user note 121337[1] into the docs. At the most we could detect the erroneous flag combination and throw an exception with a better message. [1] <http://php.net/manual/en/sqlite3.construct.php#121337>
-- Christoph M. Becker