Bundled libraries upgrade 'process'

  99879
July 17, 2017 14:12 danack@basereality.com (Dan Ackroyd)
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
  99880
July 17, 2017 16:04 ryan.jentzsch@gmail.com (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?

- Ryan



On Mon, Jul 17, 2017 at 8:12 AM, Dan Ackroyd <danack@basereality.com> wrote:

> 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 > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > >
  99881
July 17, 2017 16:10 lists@rhsoft.net ("lists@rhsoft.net")
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
> On Mon, Jul 17, 2017 at 8:12 AM, Dan Ackroyd <danack@basereality.com> wrote: > >> 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
  99883
July 17, 2017 18:09 cmbecker69@gmx.de ("Christoph M. Becker")
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
  99886
July 18, 2017 08:42 danack@basereality.com (Dan Ackroyd)
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
  99888
July 18, 2017 10:15 weltling@outlook.de (Anatol Belski)
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
  99892
July 18, 2017 11:07 cmbecker69@gmx.de ("Christoph M. Becker")
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