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
- 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
On Sat, 1 Oct 2005 16:17:19 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
- 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.
- PHP 5.1 compatible code.
It is compatible, or do you mean E_STRICK compatible?
--Pierre
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:
- 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.
- PHP 5.1 compatible code.
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
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:
On Sat, 1 Oct 2005 16:17:19 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
- 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.
- PHP 5.1 compatible code.
It is compatible, or do you mean E_STRICK compatible?
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
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:
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:
- 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.
- PHP 5.1 compatible code.
It is compatible, or do you mean E_STRICK compatible?
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.
Then you don't suit php development and should get stripped out - end
of discussion - do what ever you want then!
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?
You need to provide a 5+ version of core pear components so that we cn ship
those with 5.1.
Best regards,
Marcus
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
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.
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
Derick Rethans 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_STRICTwarnings 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
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
On Sat, 1 Oct 2005 16:17:19 +0200 (CEST)
derick@php.net (Derick Rethans) wrote:
But it seems
E_STRICTis 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
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
}^MBut it seems
E_STRICTis turned on later for some reason too. Can this
code please be upgraded to 1. not modify any error reporting setting and
- 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
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
It appears that
E_STRICTis 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 likeis_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
Derick Rethans wrote:
It appears that
E_STRICTis 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...
Could it be that by disabling php.iniwith -n, error_reporting() no
longer functions as documented?
Greg
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
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.
- 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.
- 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.
Curt Zirzow wrote:
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_STRICTissue... I ran into two issues while
installing php 5.1-branch.
- 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.
- 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
Curt Zirzow wrote:
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?
- 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).
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.
- 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)
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.
- 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).
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
- 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).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
- 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).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.
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
Derick Rethans wrote:
- 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).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?
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. ;)
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
}^MBut it seems
E_STRICTis turned on later for some reason too. Can this
code please be upgraded to 1. not modify any error reporting setting and
- PHP 5.1 compatible code. Currently installing pear does not seem
to work at all with the .phar.regards,
DerickDerick Rethans
http://derickrethans.nl | http://ez.no | http://xdebug.org