# phar and e_strict - Thread: https://externals.io/message/19310 - Original archive: https://news-web.php.net/php.internals/19310 - Started by Derick Rethans on 2005-10-01T14:17:19+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #19310 — Derick Rethans — 2005-10-01T14:17:19+00:00 URL: https://externals.io/message/19310#19310 Hello! I am wondering why "make install-pear" comes up with hundreds of e_strict warnings? The code tests for PHP 5.1 but makes use of all old things that are now considered e_strict or deprecated. Besides this for some reason setting error_reporting to 0 doesn't help at all. First of all the code does: error_reporting(E_ALL);^M if (version_compare(phpversion(), '5.1.0b1', '<')) {^M die('Error: .phar files require PHP 5.1 or newer');^M }^M But it seems `E_STRICT` is turned on later for some reason too. Can this code please be upgraded to 1. not modify any error reporting setting and 2. PHP 5.1 compatible code. Currently installing pear does not seem to work at all with the .phar. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #19311 — Pierre — 2005-10-01T14:24:02+00:00 URL: https://externals.io/message/19310#19311 · In reply to: #19310 On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) derick@php.net (Derick Rethans) wrote: > 1. not modify any error reporting setting We have to modify it as the underlying code is not php5 _only_ but have to work for both php5 and php4. > 2. PHP 5.1 compatible code. It is compatible, or do you mean E_STRICK compatible? --Pierre --- ## #19312 — Pierre — 2005-10-01T14:30:27+00:00 URL: https://externals.io/message/19310#19312 · In reply to: #19310 On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) derick@php.net (Derick Rethans) wrote: > But it seems `E_STRICT` is turned on later for some reason too. Can > this code please be upgraded to 1. not modify any error reporting > setting and 2. PHP 5.1 compatible code. Currently installing pear > does not seem to work at all with the .phar. Forget to mention than the `E_STRICT` and is_a warnings have nothing to do with the phar itself but the PEAR code itself. --Pierre --- ## #19313 — Marcus Boerger — 2005-10-01T14:48:47+00:00 URL: https://externals.io/message/19310#19313 · In reply to: #19311 Hello Pierre, Saturday, October 1, 2005, 4:24:02 PM, you wrote: > On Sat, 1 Oct 2005 16:17:19 +0200 (CEST) > derick@php.net (Derick Rethans) wrote: > > […] > We have to modify it as the underlying code is not php5 _only_ but have > to work for both php5 and php4. > > […] > It is compatible, or do you mean E_STRICK compatible? You should face reality that php 5 is a bit different than php 4. Many of the things changed in php 5 were made to support exactly pear development but pear is absolutley ignoring it. Why can't at least the things that shall be shipped in 5.1 fashion - especially since you're doing part of it in a way only 5.1 can serve anyway. Best regards, Marcus --- ## #19314 — Pierre — 2005-10-01T15:04:01+00:00 URL: https://externals.io/message/19310#19314 · In reply to: #19313 On Sat, 1 Oct 2005 16:48:47 +0200 helly@php.net (Marcus Boerger) wrote: > Hello Pierre, > > Saturday, October 1, 2005, 4:24:02 PM, you wrote: > > > […] > > > > […] > > > […] > > > […] > > > […] > > You should face reality that php 5 is a bit different than php 4. I do know that, I did explain my opinions about having PEAR bundled by default in 5.1+ and so on. But other php developers seem to fully disagree with me on this topic, as many PEAR developers, nothing more I can do. > Many of the things changed in php 5 were made to support exactly pear > development but pear is absolutley ignoring it. As PEAR 1.4 _has_ to be compatible with 1.x, we did not ignore the changes. But we cannnot drop php4 support or maintain 2 code bases. > Why can't at least the things that shall be shipped in 5.1 fashion - > especially since you're doing part of it in a way only 5.1 can serve > anyway. I do not get this sentence, can you elaborate? --Pierre --- ## #19317 — Jani Taskinen — 2005-10-01T15:11:43+00:00 URL: https://externals.io/message/19310#19317 · In reply to: #19311 > We have to modify it as the underlying code is not php5 _only_ but have > to work for both php5 and php4. You haven't heard about branches either? :) --Jani --- ## #19318 — Marcus Boerger — 2005-10-01T15:12:21+00:00 URL: https://externals.io/message/19310#19318 · In reply to: #19314 Hello Pierre, Saturday, October 1, 2005, 5:04:01 PM, you wrote: > On Sat, 1 Oct 2005 16:48:47 +0200 > helly@php.net (Marcus Boerger) wrote: > > […] > I do know that, I did explain my opinions about having PEAR bundled by > default in 5.1+ and so on. But other php developers seem to fully > disagree with me on this topic, as many PEAR developers, nothing more I > can do. > > […] > As PEAR 1.4 _has_ to be compatible with 1.x, we did not ignore the > changes. But we cannnot drop php4 support > or maintain 2 code bases. Then you don't suit php development and should get stripped out - end of discussion - do what ever you want then! > > […] > I do not get this sentence, can you elaborate? You need to provide a 5+ version of core pear components so that we cn ship those with 5.1. Best regards, Marcus --- ## #19315 — Greg Beaver — 2005-10-01T15:21:57+00:00 URL: https://externals.io/message/19310#19315 · In reply to: #19310 Derick Rethans wrote: > Hello! > > I am wondering why "make install-pear" comes up with hundreds of > e_strict warnings? The code tests for PHP 5.1 but makes use of all old > things that are now considered e_strict or deprecated. Besides this for > some reason setting error_reporting to 0 doesn't help at all. First of > all the code does: > > error_reporting(E_ALL);^M > if (version_compare(phpversion(), '5.1.0b1', '<')) {^M > die('Error: .phar files require PHP 5.1 or newer');^M > }^M > > But it seems `E_STRICT` is turned on later for some reason too. Can this > code please be upgraded to 1. not modify any error reporting setting and > 2. PHP 5.1 compatible code. Currently installing pear does not seem > to work at all with the .phar. This is a bit baffling: even a full text search of the entirety of cvs pear-core/ turns up only 1 reference to `E_STRICT` in the code (there are others in the in-code documentation) - and this is in a file that is not used by the .phar (pearcmd.php). A search for "error_reporting(" only turns up "error_reporting(E_ALL)." As Derick notes, this is also the first thing present in the .phar before any other code is included. It appears that `E_STRICT` is being triggered even though it is explicitly NOT asked for. All the same, I added another redundant `error_reporting()` call at the top of install-pear.php, re-built the .phar and committed to pearweb. Hopefully this will fix the issue. The code *is* PHP 5.1-compatible. Understand that the .phar uses PEAR to install things. PEAR uses things like `is_a()` and "var" and calling static methods because there are no alternatives unless we drop PHP 4.x support entirely from the pear command. Until all the standard unix distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the standard PHP version, this isn't an option. I've been running the pear command using PHP 5.1rc1 ever since it came out, and it works just fine. This is a problem specific to the install-pear.phar that in fact did not happen just 2 weeks ago - perhaps something has changed in PHP 5.1 itself? Greg --- ## #19316 — Jani Taskinen — 2005-10-01T15:29:39+00:00 URL: https://externals.io/message/19310#19316 · In reply to: #19315 > support entirely from the pear command. Until all the standard unix > distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the > standard PHP version, this isn't an option. And as long as you keep it backwards-compatible, they won't upgrade. (ever heard about the chicken that was before the egg? :) --Jani --- ## #19319 — Derick Rethans — 2005-10-01T15:50:02+00:00 URL: https://externals.io/message/19310#19319 · In reply to: #19315 > It appears that `E_STRICT` is being triggered even though it is explicitly > NOT asked for. All the same, I added another redundant > `error_reporting()` call at the top of install-pear.php, re-built the > .phar and committed to pearweb. Hopefully this will fix the issue. I tested with the new code, and for some reason it still doesn't work. Interesting is that if I remove the -n from the PEAR_INSTALL_OPTIONS in the makefile, it doesn't show the e_Strict errors anymore... > The code *is* PHP 5.1-compatible. Understand that the .phar uses PEAR > to install things. PEAR uses things like `is_a()` and "var" and calling > static methods because there are no alternatives unless we drop PHP 4.x > support entirely from the pear command. Until all the standard unix > distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the > standard PHP version, this isn't an option. Branches? :) regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #19320 — dufuz@php.net — 2005-10-01T15:59:26+00:00 URL: https://externals.io/message/19310#19320 · In reply to: #19315 > Until all the standard unix > distros (gentoo/redhat/debian/etc.) start distributing PHP 5.x as the > standard PHP version, this isn't an option. Just so you know, Fedora and FreeBSD have had 5.x as standard for some time now ;-) I can't speak for others but I think it's the same for RHEL 4 and probably Gentoo. So in a way I agree with Jani, specially since many distros are already moving to 5.x - Helgi --- ## #19321 — Greg Beaver — 2005-10-01T15:59:34+00:00 URL: https://externals.io/message/19310#19321 · In reply to: #19319 Derick Rethans wrote: > > > > > […] > > > I tested with the new code, and for some reason it still doesn't work. > Interesting is that if I remove the -n from the PEAR_INSTALL_OPTIONS in > the makefile, it doesn't show the e_Strict errors anymore... Could it be that by disabling php.iniwith -n, `error_reporting()` no longer functions as documented? Greg --- ## #19324 — Justin Patrin — 2005-10-01T18:15:17+00:00 URL: https://externals.io/message/19310#19324 > Hello Christian, > > Saturday, October 1, 2005, 6:13:51 PM, you wrote: > > > […] > > > […] > > > […] > > Noone ever said that pear for php 4 should be frozen in the near future. > The only point is that we either need a branch or a tool that allows > automatic conversion of pear code to php 5 code. > You could do this with a post-install script quite easily. I don't think this is the point, however. Making code `E_STRICT` isn't really important. The thing that Greg wants to do is drop PHP4 support completely. This would make the code less complicated and make support easier. -- Justin Patrin --- ## #19326 — Johannes Schlueter — 2005-10-01T23:21:13+00:00 URL: https://externals.io/message/19310#19326 · In reply to: #19310 Hi, on a related note on the .phar stuff: I've just built PHP without zlib support and the PEAR install failed with | Installing PEAR environment: /opt/php-5.1-dev/lib/php/ | | Notice: Error: zlib extension is not enabled - `gzinflate()` function needed | for compressed .phars in /.../PHP_5_1/pear/install-pear.phar on line 393 | | Warning: main(phar://install-pear.phar/index.php): failed to open stream: | "PHP_Archive::stream_open" call failed | in /.../PHP_5_1/pear/install-pear.phar on line 633 | | Fatal error: main(): Failed opening required | 'phar://install-pear.phar/index.php' (include_path='.:') | in /home/johannes/src/php/cv/PHP_5_1/pear/install-pear.phar on line 633 | | make[1]: *** [install-pear-installer] Error 255 In my opinion there should be a nicer error message, maybe even at configure time. johannes > Hello! > > I am wondering why "make install-pear" comes up with hundreds of > e_strict warnings? The code tests for PHP 5.1 but makes use of all old > things that are now considered e_strict or deprecated. Besides this for > some reason setting error_reporting to 0 doesn't help at all. First of > all the code does: > > error_reporting(E_ALL);^M > if (version_compare(phpversion(), '5.1.0b1', '<')) {^M > die('Error: .phar files require PHP 5.1 or newer');^M > }^M > > But it seems `E_STRICT` is turned on later for some reason too. Can this > code please be upgraded to 1. not modify any error reporting setting and > 2. PHP 5.1 compatible code. Currently installing pear does not seem > to work at all with the .phar. > > regards, > Derick > -- > Derick Rethans > http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #19358 — Curt Zirzow — 2005-10-03T19:03:51+00:00 URL: https://externals.io/message/19310#19358 · In reply to: #19315 > > I've been running the pear command using PHP 5.1rc1 ever since it came > out, and it works just fine. This is a problem specific to the > install-pear.phar that in fact did not happen just 2 weeks ago - perhaps > something has changed in PHP 5.1 itself? A little side track on the `E_STRICT` issue... I ran into two issues while installing php 5.1-branch. 1. zlib is required now with php, and by default php isn't installed with zlib nor does configure catch this, so, while make install is running and when pear is being installed make dies leaving a bad installation. I have have a patch for configure.in that is ready that will add a check for zlib in the configure process to avoid the make install bailing. 2. I'm not sure if the release of php5.1 is going to include the install-pear.phar file, but if I don't have that file within the pear/ directory, make install also requires that the system has wget installed, causing a fail in make install as well. I can write a patch for configure.in to check for wget (or fetch on *bsd machines), if the .phar file isn't going to be included with a release. heck, here is the patch for #1: http://zirzow.org/patches/pear.configure.in.patch I'm not really sure what to do with #2, i just thought i'd bring up these issues while talking about the install process. Curt. --- ## #19360 — Curt Zirzow — 2005-10-03T22:35:52+00:00 URL: https://externals.io/message/19310#19360 · In reply to: #19359 > Curt Zirzow wrote: > > […] > > I could eliminate this requirement, at the expense of a larger .phar file > (3.3MB instead of 640k). Yeah, that could work. On the other hand I think most/many people will have zlib included. So in that case the installer could/should first check for a compressed file [.phaz?] (if it supports the compression) otherwise just use the uncompressed file. > > […] > > Better (I discussed this with Andi, but haven't had time to do anything > fruitful yet) is to write a short PHP script that would download it. Just > now, it occurs to me that by changing the wget call in Makefile.frag from: > > wget http://pear.php.net/install-pear.phar -nd -P $(srcdir); > > to: > > @$(top_builddir)/sapi/cli/php -dallow_url_fopen=1 -r "$a = > file_get_contents('http://pear.php.net/install-pear.phar');file_put_contents($_SERVER['argv'][1] > . '/install-pear.phar',$a);" $(srcdir) At first look this looks like a good solution, i don't know if it is due to a bad copy paste but my test fails right now. The only problem i see with this is that this occurs on 'make install'. I think ideally the download should at least occur in the configure or make process, especially since pear gets installed so late in the process. If the download fails for what ever reason, the person is going to have a partially installed php. Curt. --- ## #19359 — Greg Beaver — 2005-10-04T04:27:31+00:00 URL: https://externals.io/message/19310#19359 · In reply to: #19358 Curt Zirzow wrote: > > > > […] > > > A little side track on the `E_STRICT` issue... I ran into two issues while > installing php 5.1-branch. > > 1. zlib is required now with php, and by default php isn't installed > with zlib nor does configure catch this, so, while make install is > running and when pear is being installed make dies leaving a bad > installation. I could eliminate this requirement, at the expense of a larger .phar file (3.3MB instead of 640k). > I have have a patch for configure.in that is ready that will add a check > for zlib in the configure process to avoid the make install bailing. > > 2. I'm not sure if the release of php5.1 is going to include the > install-pear.phar file, but if I don't have that file within the pear/ > directory, make install also requires that the system has wget > installed, causing a fail in make install as well. > > I can write a patch for configure.in to check for wget (or fetch on *bsd > machines), if the .phar file isn't going to be included with a release. Better (I discussed this with Andi, but haven't had time to do anything fruitful yet) is to write a short PHP script that would download it. Just now, it occurs to me that by changing the wget call in Makefile.frag from: wget http://pear.php.net/install-pear.phar -nd -P $(srcdir); to: @$(top_builddir)/sapi/cli/php -dallow_url_fopen=1 -r "$a = file_get_contents('http://pear.php.net/install-pear.phar');file_put_contents($_SERVER['argv'][1] . '/install-pear.phar',$a);" $(srcdir) this might be our cross-platform ticket. Could one of you kind folks try this, and commit if it works? Thanks, Greg --- ## #19362 — Derick Rethans — 2005-10-04T07:20:44+00:00 URL: https://externals.io/message/19310#19362 · In reply to: #19359 > > […] > > I could eliminate this requirement, at the expense of a larger .phar > file (3.3MB instead of 640k). Please don't do that, as this is going to be part of a release tarball. > @$(top_builddir)/sapi/cli/php -dallow_url_fopen=1 -r "$a = > file_get_contents('http://pear.php.net/install-pear.phar');file_put_contents($_SERVER['argv'][1] > . '/install-pear.phar',$a);" $(srcdir) > > this might be our cross-platform ticket. Could one of you kind folks > try this, and commit if it works? I don't think we should do this for our releases, it's going to open way too much cans of worms. Currently the phar still throws still lots of e_strict errors. When that is fixed I'll add a script that puts the phar in the snapshots too. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #19375 — Lukas Smith — 2005-10-04T08:59:59+00:00 URL: https://externals.io/message/19310#19375 · In reply to: #19313 Marcus Boerger wrote: > You should face reality that php 5 is a bit different than php 4. > Many of the things changed in php 5 were made to support exactly pear > development but pear is absolutley ignoring it. Why can't at least the > things that shall be shipped in 5.1 fashion - especially since you're doing > part of it in a way only 5.1 can serve anyway. We are not ignoring it. However the single most useful feature from PEAR POV was dropped from PHP5: namespaces. Without it we just could not justify dumping our PHP4 userbase and so we decided to try peaceful coexistance, however increasingly new packages are PHP5 only and those packages do not rely in the core PEAR classes, since the main purpose of these classes is error handling which we have decided to move to exceptions (something I personally thought was a bad idea). However the PEAR installer will have to work with PHP4 for sometime and we simply do not have the ressources to maintain two versions of the PEAR installer. Finally the PEAR installer is a more or less self contained application tool. As long as it works it does not need to follow any particular error handling defined for any apps written by users. So all we have to do is make sure that we can disable `E_STRICT` for the PEAR installer when run in an environment that usually runs in E_STRICT. regards, Lukas --- ## #19376 — Stefan Walk — 2005-10-04T09:00:58+00:00 URL: https://externals.io/message/19310#19376 · In reply to: #19362 > > > > […] > > Please don't do that, as this is going to be part of a release tarball. This tarball is gzipped/bzip2ed though, or am I mistaken? So it wouldn't matter for the size of the tarball if the .phar file is not compressed. Regards, Stefan --- ## #19377 — Derick Rethans — 2005-10-04T09:04:55+00:00 URL: https://externals.io/message/19310#19377 · In reply to: #19375 > Marcus Boerger wrote: > > > […] > > We are not ignoring it. However the single most useful feature from PEAR POV > was dropped from PHP5: namespaces. That's lame, this has nothing to do with `E_STRICT` warnings or other dubious code. regards, Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #19378 — Lukas Smith — 2005-10-04T09:07:58+00:00 URL: https://externals.io/message/19310#19378 · In reply to: #19377 Derick Rethans wrote: > > […] > > > That's lame, this has nothing to do with `E_STRICT` warnings or other > dubious code. How is it dubious to support PHP4 and PHP5 with the same code base? There have been definate improvements, no doubt about that. But nothing grand enough to say: "he lets start from scratch". regards, Lukas --- ## #19379 — Derick Rethans — 2005-10-04T09:09:14+00:00 URL: https://externals.io/message/19310#19379 · In reply to: #19376 > > > […] > > This tarball is gzipped/bzip2ed though, or am I mistaken? So it > wouldn't matter for the size of the tarball if the .phar file is not > compressed. Well, that is true :) It would be nice if somebody could check out the difference in size though. Derick -- Derick Rethans http://derickrethans.nl | http://ez.no | http://xdebug.org --- ## #19401 — Matthew Kavanagh — 2005-10-04T15:10:03+00:00 URL: https://externals.io/message/19310#19401 · In reply to: #19362 Derick Rethans wrote: > > > > > […] > > > Please don't do that, as this is going to be part of a release tarball. Would that really be a problem, given that compressing a compressed file and compressing an uncompressed file will usually yield similar sized resultant files? --- ## #19402 — Matthew Kavanagh — 2005-10-04T15:21:53+00:00 URL: https://externals.io/message/19310#19402 · In reply to: #19401 Matthew Kavanagh wrote: > Would that really be a problem, given that compressing a compressed file > and compressing an uncompressed file will usually yield similar sized > resultant files? > ...and I failed to see the previous email that says the same thing. Genius at work. ;)