PHP 5.2.5 when ?

Thanks! I'll get back on this tomorrow (time for sleep now!)..

Do you mind if I mail the details directly to you?

Cheers,

Bart

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--==============36708429=Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig6D90A361E6459C37DE577D78"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6D90A361E6459C37DE577D78
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Bart wrote:
>
>
> Johnny Hughes wrote:
>> Bart wrote:
>>>
>>>
>>> Johnny Hughes wrote:
>>>> Bart wrote:
>>>>> Well, life is not that black and white, luckily ;)
>>>>>
>>>>> Try authenticating with PHP to MySQL using certificates. That won't
>>>>> work with the current PHP release shipped with RHEL/CentOS. There's
>>>>> a bug in PHP 5.1 and it's fixed in 5.2. Since this is not a
>>>>> security bug, but just missing (of wrongly implemented)
>>>>> functionality, it's probably not going to be back ported.
>>>>>
>>>>> Since certificates (and PKI) are a pretty hot item these days, an
>>>>> upgrade can be very useful.
>>>>>
>>>>> Just an idea that upgrading is not always about having the latest
>>>>> and greatest.. ;)
>>>>
>>>> Did you file a bug that says, hey ... your php is broken like this,
>>>> here is what it will not do ?
>>>>
>>>> If so, what is the upstream bug so I can track it ... if not, why
>>>> not :D
>>>>
>>> No, we did not ;) We opened a Service Request at RHEL, and asked them
>>> if php bug #37620 will be fixed, or if they will upgrade to php 5.2.
>>> The response we got was that RH is selling RH Application Stack v2,
>>> which does include php 5.2. And they asked us if there is an CVEs
>>> related to this bug..
>>>
>>> Bottom line was.. either buy the application stack, or hand over the
>>> CVEs. Since this bug is not security related, there is no CVEs.
>>
>> Is this what you are talking about???
>>
>> http://bugs.php.net/bug.php?id=37620
>>
>> and if so, explain how that affects PKI authorization and I will be
>> glad to file a bug and make lots of community noise ...
>>
>> Or if you would, file a bug on bugs.centos.org that explains exactly
>> how pki cna not be used with php and I will file an upstream bug to
>> see if they will fix it.
>>
>> Now, they will not fix every bug, but non-functional PKI is one I
>> think that they will address.
>>
>
> Thanks! I'll get back on this tomorrow (time for sleep now!)..
>
> Do you mind if I mail the details directly to you?
>

Directly to me is fine, yes.


--------------enig6D90A361E6459C37DE577D78
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

php is not a major component of RHEL/CentOS.
Upgrading PHP is not going to break the system. Worst case scenario it
does not work as well, in which case it is trivial to remove it and
install the vendor version.

Now if he had been asking for the new version of gnome or something like
that, then your analogy would be correct.

There are legitimate reasons to run CentOS 5 and update the installed php.
Most users are probably better off with the CentOS provided version, but
not everyone fits the description of most users.

I do what I do because it makes life easier for me. Normally life is
easier for me when I do not replace the OS Vendor packages. Sometimes,
however, a few things are easier when I do. php 5.2.5 is an example for
me. I do not know if it is the case for the OP or not, maybe he would be
better with 5.1.x - but if he needs 5.2.x there's a damn good chance
installing CentOS and replacing the php will give him a far more stable
system then installing Fedora 8 would.

Johnny,
it doesn't work the way you say. I can name two bugs I consider serious:
https://bugzilla.redhat.com/show_bug.cgi?id=178417
https://bugzilla.redhat.com/show_bug.cgi?id=243909

They are long-term bugs with no results. :o(
Regards,
David

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--==============54547521=Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="------------enig77E20986A44EF64BD8022A41"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig77E20986A44EF64BD8022A41
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: quoted-printable

Michael A. Peters wrote:
> Scott Silva wrote:
>>
>> |
>> I can't understand why people choose an enterprise distro for it's
>> longevity,
>> and then proceed to try and break it. It is almost like buying a brand
>> new car
>> and then immediately replacing the engine.
> php is not a major component of RHEL/CentOS.
> Upgrading PHP is not going to break the system. Worst case scenario it
> does not work as well, in which case it is trivial to remove it and
> install the vendor version.
>
> Now if he had been asking for the new version of gnome or something like
> that, then your analogy would be correct.
>
> There are legitimate reasons to run CentOS 5 and update the installed php.
> Most users are probably better off with the CentOS provided version, but
> not everyone fits the description of most users.
>
> I do what I do because it makes life easier for me. Normally life is
> easier for me when I do not replace the OS Vendor packages. Sometimes,
> however, a few things are easier when I do. php 5.2.5 is an example for
> me. I do not know if it is the case for the OP or not, maybe he would be
> better with 5.1.x - but if he needs 5.2.x there's a damn good chance
> installing CentOS and replacing the php will give him a far more stable
> system then installing Fedora 8 would.

If you knew exactly what you were doing and how to make your own php ...
and you had a very good reason (a bug that is not be fixed, etc.), then
that might be the case.

If this were RHEL though, you just lost any php support you could get
upstream (and anything else that they MIGHT be able to relate to your
replaced packages).

IF you are willing to do that, I guess it would be fine.

But for MOST users, this is not the case.  And BTW, any of the LAMP 
components I would consider a MAJOR part of the OS.

Since you redid php, you are now possibly going to need to recompile
many other things including the php-* extensions from DAG's repo and the
CentOS repos, php-mysql, etc.  I do not know the impact as I have not 
actually done the analysis.  Since /usr/lib/httpd/modules/libphp5.so 
MIGHT be the same name for both (though might have different content),
you may not need to recompile any apache modules or other items.

But, I still think php is a major item and would probably rebuild my
whole mysql / php / apache if i was considering a php upgrade.


--------------enig77E20986A44EF64BD8022A41
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

Apache and MySQL probably are major components. Lots of CentOS packages
depend upon them.
PHP is a module that adds functionality to Apache. The only parts of the
distribution that depend upon PHP are some of the web applications, such
as squirelmail, the php-pear stuff, and a few php modules that are not
built as part of main php package.

Most php extensions will work without a rebuild. Some may require a
rebuild, but that's what rpmbuild --rebuild is for (or mock, which is
cleaner way of doing rpmbuild --rebuild)
>
> Since you redid php, you are now possibly going to need to recompile
> many other things including the php-* extensions from DAG's repo and
> the CentOS repos, php-mysql, etc.
I do not use DAG's repo. php-mysql etc. are all built during the build
of php. The src.rpm for php builds the vast majority of modules. A few
modules, like php-pecl-Fileinfo are not part of the main php package -
and while I did personally rebuild the CentOS src.rpm for that module, I
tested the one in CentOS and it worked without a rebuild.

Any of the php modules that have "5.1.6" in the version (from CentOS and
CentOS Extras) are modules that are distributed with php and are rebuilt
by the single 5.2.5 src.rpm.
> I do not know the impact as I have not actually done the analysis.
> Since /usr/lib/httpd/modules/libphp5.so MIGHT be the same name for
> both (though might have different content), you may not need to
> recompile any apache modules or other items.
No - you do not need to recompile any other apache modules. Apache
itself does not require php, and none of the other apache modules
require it either.

The only packages you may have to recompile are packages that have a
BuildRequires: php-devel in them.
And going from 5.1.6 to 5.2.x generally does not, as they share the same
zend api version. I don't know of a case where a module external to php
requires a rebuild, though I suppose it is possible they exist.
>
> But, I still think php is a major item and would probably rebuild my
> whole mysql / php / apache if i was considering a php upgrade.
No. PHP depends upon Apache and MySQL. Neither of those packages depend
upon PHP. PHP is not installed in the build system when those packages
are compiled, there is no way that upgrading php will break either of them.

That being said - I absolutely agree that unless you *know* you need PHP
5.2.x then you should stick to the version in your distribution.

Web hosts have lost my business because they upgraded the version of PHP
they were running without telling me at least six months in advance -
causing breakage of code. Many web hosts are still on PHP 4 for that
reason. Good web hosts will set up a new server with newer versions of
PHP and ask you if you want your domain switched to it - but don't force
you to move.

It is possible there are some web applications that work with 5.1.6 that
do not work in 5.2.5 though I have not experienced any, and looking at
their changelog, it looks like there are very few differences that might
require patching of clean code. Hell, I'm occasionally paid to port
stuff from php 3 to php 5 - and often, had they used proper code in php3
- the changes I make wouldn't be necessary.

There may be new bugs, that is always a risk when upgrading, and why it
is best to stick with CentOS version unless you *know* you need newer.
My laptop uses the CentOS version, for example, even though I'm
confident in my php 5.2.5 packages - as nothing I'm developing on my
laptop requires 5.2.x

Back to the point though, PHP is not a major component of RHEL/CentOS.
It the last part of a LAMP that gets installed, LAM does not need php,
php needs LAM (well, you could use Windows, IIS, Oracle ... so I guess
technically not ... but anyway ...)

Very few packages that are not built from the same src.rpm as php itself
depend upon it, and they are generally not very specific version dependent.

Michael A. Peters wrote:
> PHP is a module that adds functionality to Apache. The only parts of the

PHP is the programming language that drives a large chunk of web
applications out there. It is not just an apache module.

> Back to the point though, PHP is not a major component of RHEL/CentOS.
> It the last part of a LAMP that gets installed, LAM does not need php,
> php needs LAM (well, you could use Windows, IIS, Oracle ... so I guess
> technically not ... but anyway ...)

The point is that replacing PHP and NOT replacing all the other pieces
of glue (apache php modules, mysql php modules ...) breaks support and
introduces many unknowns into the system. Many websites would not work
if you ran it on just LAM, as the code is written in PHP and PHP needs
to interact with the other components. In my book PHP is a major part of
a web server.

PHP is a major component of LAMP and replacing it just because there is
a new version of PHP out with some new features and maybe some bugfixes
you don't need is NOT a good enough reason to go through all that
hassle. YMMV. The upstream provider will backport fixes that are
important enough to backport. With an enterprise distro of Linux, you
make the apps work with what is in the base distro, NOT the other way
around.

You can of course do whatever you want with the computers you control,
but I really disagree that PHP is a minor component and that building
your own is easy and with no consequences to talk about.

//Morten

Morten Torstensen wrote:
> Michael A. Peters wrote:
>> PHP is a module that adds functionality to Apache. The only parts of the
>
> PHP is the programming language that drives a large chunk of web
> applications out there. It is not just an apache module.
Granted. It's most common use is as an apache module, it can be used for
several other things.
>
>> Back to the point though, PHP is not a major component of
>> RHEL/CentOS. It the last part of a LAMP that gets installed, LAM does
>> not need php, php needs LAM (well, you could use Windows, IIS, Oracle
>> ... so I guess technically not ... but anyway ...)
>
> The point is that replacing PHP and NOT replacing all the other pieces
> of glue (apache php modules, mysql php modules ...) breaks support and
> introduces many unknowns into the system. Many websites would not work
> if you ran it on just LAM, as the code is written in PHP and PHP needs
> to interact with the other components. In my book PHP is a major part
> of a web server.
PHP is a major part of a web server, yes - but it is an easily
replaceable component of CentOS without sacrificing the stability of
CentOS. The php source RPM builds php, php-common, php-cli, and almost
all of the php modules that are available to CentOS from the CentOS
repositories. You rebuild a newer version, and you get a new set that
bolts in in place of the old set.
>
> PHP is a major component of LAMP and replacing it just because there
> is a new version of PHP out with some new features and maybe some
> bugfixes you don't need is NOT a good enough reason to go through all
> that hassle.
I agree. One should only upgrade when a new feature really is a necessity.
> YMMV. The upstream provider will backport fixes that are important
> enough to backport. With an enterprise distro of Linux, you make the
> apps work with what is in the base distro, NOT the other way around.
That is not always the best solution.
The current problem I am solving by using php 5.2.5 can only be done in
stock CentOS 5 by using perl. PHP does not have the functionality and
the pecl extension that does requires php 5.2.x. Maybe that pecl
extension could be ported to work in 5.1.x but it hasn't been and I
don't feel qualified to do it, nor am I willing to pay a programmer to
do it when there is a simple solution - use php 5.2.x.
>
> You can of course do whatever you want with the computers you control,
> but I really disagree that PHP is a minor component and that building
> your own is easy and with no consequences to talk about.
I never said there are no consequences.
The biggest consequence - RHEL/CentOS will not support it.
However - reverting to CentOS php is as easy as a yum remove followed by
a yum install and restarting the web server.

Also note that on the repo page where I make my build available, I tell
users they are probably better off with the stock php - because they
probably are. There are situations where the stock php does not do what
you need it to do, and in those cases, the drawbacks of losing upstream
support may be outweighed by the benefit of having your stable CentOS
LAMP do what you need it to do.

If the support cycle of Fedora wasn't so darned short, perhaps Fedora
would be better for people who need a newer PHP - but Fedora's life
cycle is so short that by the time it is robust it is near EOL. The
fallout of that decision by the Fedora team is that people who need a
long lasting distribution with just a few components like PHP updated
are going to use CentOS with those few components updated. That may not
be what you consider to be "Enterprise Linux" but one of the major
strong points of FOSS is that you don't need to wait for a vendor to
patch something or provide function you need.

PHP is a relatively low risk component to update if the update is
packaged correctly. It's not no risk, but it is a low risk update.

MySQL on the other hand is not - since there are several apps that link
against it. LDAP is not because there are several apps that link against
it. Apache is not because there are several apps that link against it.
Etc. - but php from 5.1.6 to 5.2.5 is a fairly straight forward
replacement. There are not a lot of changes that require change of
existing code to properly run, and the vast majority of binary modules
just work as the zend api has not changed.

Most of the 3rd party php web applications out there have been tested in
5.2.x for some time. Not all have, but those that don't work probably
have problems in 5.1.6 as well (these would primarily be web apps that
still want php 4)

I need to make a correction - the zend abi (not api) has changed - but
modules built against the old abi work in the new abi.

php 5.1.6 zend-abi = 20050922
php 5.2.5 zend-abi = 20060613