FAQ
Hi

When (some) expected rpm package for the upgrade php to version 5.2.5(CentOS4) ?
Who knows?

--
wbr
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.centos.org/pipermail/centos/attachments/20080111/be78b7db/attachment.htm

Search Discussions

  • Johnny Hughes at Jan 11, 2008 at 10:05 am

    Santa Claus wrote:
    Hi

    When (some) expected rpm package for the upgrade php to version 5.2.5(CentOS4) ?
    Who knows?
    ummm ... the answer is probably never.

    Red Hat offers a RHWAS ... that has a php5 for EL4. The version of php
    in there (and in our CentOSPlus repo) is php-5.1.6 ... it might go
    higher than that, but I doubt it will go to 5.2.x. If it does go there
    in RHWAS, it will also go there in CentOSPlus, but I would not hold my
    breath :-D

    Thanks,
    Johnny Hughes

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 252 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20080111/188fdc9a/signature.bin
  • Mark Weaver at Jan 13, 2008 at 1:03 pm

    On Fri, 11 Jan 2008 04:05:56 -0600 Johnny Hughes wrote:

    Santa Claus wrote:
    Hi

    When (some) expected rpm package for the upgrade php to version
    5.2.5(CentOS4) ? Who knows?
    ummm ... the answer is probably never.

    Red Hat offers a RHWAS ... that has a php5 for EL4. The version of
    php in there (and in our CentOSPlus repo) is php-5.1.6 ... it might
    go higher than that, but I doubt it will go to 5.2.x. If it does go
    there in RHWAS, it will also go there in CentOSPlus, but I would not
    hold my breath :-D

    Thanks,
    Johnny Hughes
    My question would be, "good god...why?" There are a ton of security
    holes in php5. From experience one of the holes I'm painfully aware of
    is php-cli which installs by default with the rest of php5.

    Mark
  • Joshua Baker-LePain at Jan 13, 2008 at 7:25 pm
    On Sun, 13 Jan 2008 at 8:03am, Mark Weaver wrote
    On Fri, 11 Jan 2008 04:05:56 -0600
    Johnny Hughes wrote:
    ummm ... the answer is probably never.

    Red Hat offers a RHWAS ... that has a php5 for EL4. The version of
    php in there (and in our CentOSPlus repo) is php-5.1.6 ... it might
    go higher than that, but I doubt it will go to 5.2.x. If it does go
    there in RHWAS, it will also go there in CentOSPlus, but I would not
    hold my breath :-D
    My question would be, "good god...why?" There are a ton of security
    holes in php5. From experience one of the holes I'm painfully aware of
    is php-cli which installs by default with the rest of php5.
    Even an exteremely brief search of the archives of this list would turn up
    tons of similar questions, and the same answer every time -- Red Hat
    backports security fixes to the stable version of packages in their
    Enterprise distro. That's why, e.g., for it's entire 5 year supported
    life, RHEL5 will be based on kernel 2.6.18. However the base kernel will
    be heavily patched for security, driver upgrades, and new hardware
    support. They treat all packages (including PHP) similarly.

    --
    Joshua Baker-LePain
    QB3 Shared Cluster Sysadmin
    UCSF
  • Mark Weaver at Jan 13, 2008 at 7:14 pm

    On Sun, 13 Jan 2008 14:25:36 -0500 (EST) Joshua Baker-LePain wrote:

    On Sun, 13 Jan 2008 at 8:03am, Mark Weaver wrote
    On Fri, 11 Jan 2008 04:05:56 -0600
    Johnny Hughes wrote:
    ummm ... the answer is probably never.

    Red Hat offers a RHWAS ... that has a php5 for EL4. The version of
    php in there (and in our CentOSPlus repo) is php-5.1.6 ... it might
    go higher than that, but I doubt it will go to 5.2.x. If it does
    go there in RHWAS, it will also go there in CentOSPlus, but I
    would not hold my breath :-D
    My question would be, "good god...why?" There are a ton of security
    holes in php5. From experience one of the holes I'm painfully aware
    of is php-cli which installs by default with the rest of php5.
    Even an exteremely brief search of the archives of this list would
    turn up tons of similar questions, and the same answer every time --
    Red Hat backports security fixes to the stable version of packages in
    their Enterprise distro. That's why, e.g., for it's entire 5 year
    supported life, RHEL5 will be based on kernel 2.6.18. However the
    base kernel will be heavily patched for security, driver upgrades,
    and new hardware support. They treat all packages (including PHP)
    similarly.
    those patches didn't do much for keeping one of my systems from being
    breached via php. from the looks of the web server logs as well as the
    messages log file that's where they got in.

    being the anul sort I am I first thought they'd breached the system
    through ssh, but that wasn't the case.

    Mark
  • Karanbir Singh at Jan 14, 2008 at 12:15 am

    Mark Weaver wrote:
    those patches didn't do much for keeping one of my systems from being
    breached via php. from the looks of the web server logs as well as the
    messages log file that's where they got in.
    I am still waiting for you to post some demonstrate-able exploit in the
    distro supplied php packages.

    - KB
  • Mark Weaver at Jan 13, 2008 at 9:09 pm

    On Mon, 14 Jan 2008 00:15:27 +0000 Karanbir Singh wrote:

    Mark Weaver wrote:
    those patches didn't do much for keeping one of my systems from
    being breached via php. from the looks of the web server logs as
    well as the messages log file that's where they got in.
    I am still waiting for you to post some demonstrate-able exploit in
    the distro supplied php packages.

    - KB
    while I understand why you'd like proof of concept for the exploit it's
    not something I'd post on a public mailing list. Not to mention the
    exploit was trashed when I reloaded the system. At the time it didn't
    seem expedient for to save that which killed my server for posterity.

    Mark
  • Karanbir Singh at Jan 14, 2008 at 2:31 am

    Mark Weaver wrote:
    while I understand why you'd like proof of concept for the exploit it's
    not something I'd post on a public mailing list. Not to mention the
    exploit was trashed when I reloaded the system. At the time it didn't
    seem expedient for to save that which killed my server for posterity.
    security@centos.org is where I'd expect you to post that to.

    Also, if you dont know what you are fixing, you dont have anything to
    benchmark against 5.2.5 either.

    As has already been pointed out in the thread, its highly likely that if
    the exploit was via a php app, its going to be an app specific exploit.
    Reloading that is going to bring that right back.

    Selinux normally helps prevent situations like this.

    - KB
  • Mark Weaver at Jan 13, 2008 at 9:53 pm

    On Mon, 14 Jan 2008 02:31:28 +0000 Karanbir Singh wrote:

    Mark Weaver wrote:
    while I understand why you'd like proof of concept for the exploit
    it's not something I'd post on a public mailing list. Not to
    mention the exploit was trashed when I reloaded the system. At the
    time it didn't seem expedient for to save that which killed my
    server for posterity.
    security@centos.org is where I'd expect you to post that to.

    Also, if you dont know what you are fixing, you dont have anything to
    benchmark against 5.2.5 either.

    As has already been pointed out in the thread, its highly likely that
    if the exploit was via a php app, its going to be an app specific
    exploit. Reloading that is going to bring that right back.

    Selinux normally helps prevent situations like this.

    - KB
    ah, yes... SELinux... Well, that was actually on the system at the time
    of the "second" breach. Getting the apps existing on the web server to
    play nicely in that environment was quite a trick, but they managed to
    breach a second time anyway.

    If I can find any remaining information from that time I'll post as
    you've suggested.

    Mark
  • Ray Van Dolson at Jan 14, 2008 at 12:25 am

    On Sun, Jan 13, 2008 at 02:14:04PM -0500, Mark Weaver wrote:
    those patches didn't do much for keeping one of my systems from being
    breached via php. from the looks of the web server logs as well as the
    messages log file that's where they got in.

    being the anul sort I am I first thought they'd breached the system
    through ssh, but that wasn't the case.
    I'd be willing to bet it was an application-specific hole that was
    utilized to breach your system.

    Ray
  • Mark Weaver at Jan 13, 2008 at 9:12 pm

    On Sun, 13 Jan 2008 16:25:15 -0800 Ray Van Dolson wrote:
    On Sun, Jan 13, 2008 at 02:14:04PM -0500, Mark Weaver wrote:
    those patches didn't do much for keeping one of my systems from
    being breached via php. from the looks of the web server logs as
    well as the messages log file that's where they got in.

    being the anul sort I am I first thought they'd breached the system
    through ssh, but that wasn't the case.
    I'd be willing to bet it was an application-specific hole that was
    utilized to breach your system.

    Ray
    That's always a possibility, but to my knowledge it wasn't anything I
    was aware of at the time, and since I do most of my app development in
    Perl it wasn't anything I personally wrote. The only other apps that
    were on the system at the time was a php web site and forum. php-cli
    was part of the problem; i.e. the weakness that made the exploit
    possible. I personally can think of no reason at all for php-cli.

    Mark
  • Chris Mauritz at Jan 14, 2008 at 2:22 am
    Mark Weaver wrote:

    "The only other apps that were on the system at the time was a php web site and forum."

    ---

    Heh. Yep, those PHP web forums have a squeaky clean track record.

    *rolling eyes*
  • Mark Weaver at Jan 13, 2008 at 9:55 pm

    On Sun, 13 Jan 2008 21:22:20 -0500 Chris Mauritz wrote:

    Mark Weaver wrote:

    "The only other apps that were on the system at the time was a php
    web site and forum."

    ---

    Heh. Yep, those PHP web forums have a squeaky clean track record.

    *rolling eyes*
    yeah... and the one that was possibly part of the problem is now gone.
    I never restored it from backup after the second breach. The perps were
    trying after the second reload, but since that web site wasn't restored
    and running on the web server they weren't able to get in.
  • Karanbir Singh at Jan 14, 2008 at 2:59 am

    Mark Weaver wrote:
    yeah... and the one that was possibly part of the problem is now gone.
    I never restored it from backup after the second breach. The perps were
    trying after the second reload, but since that web site wasn't restored
    and running on the web server they weren't able to get in.
    now would also be a good time to plumb in remotelogging :D

    I recommend rsyslog!

    --
    Karanbir Singh
    CentOS Project { http://www.centos.org/ }
    irc: z00dax, #centos@irc.freenode.net
  • Mark Weaver at Jan 14, 2008 at 12:36 am

    On Mon, 14 Jan 2008 02:59:38 +0000 Karanbir Singh wrote:

    Mark Weaver wrote:
    yeah... and the one that was possibly part of the problem is now
    gone. I never restored it from backup after the second breach. The
    perps were trying after the second reload, but since that web site
    wasn't restored and running on the web server they weren't able to
    get in.
    now would also be a good time to plumb in remotelogging :D

    I recommend rsyslog!
    Indeed! hadn't thought of that before, but the packages have just
    finished downloading. :)
  • Jim Perrin at Jan 14, 2008 at 3:19 am

    On Jan 13, 2008 9:59 PM, Karanbir Singh wrote:

    I recommend rsyslog!
    Well okay, now you've drawn me out!

    I've been playing with rsyslog recently in the hopes of creating the
    'one monitoring server to rule them all' with logging, nagios, ibm
    director, etc. It seems the fedora/rh folks made a very good decision
    in making rsyslog the default logger in fedora 8, but it works equally
    well in centos5 as a drop in replacement for the sysklogd logger. In
    addition to the usual logging you get by default in centos, rsyslog
    also allows for log templating, regex filtering, alerts, tcp and udp
    delivery, logging to database (mysql, but soon postgres) and sane
    multi-host log handling. It's a very good competitor to syslog-ng,
    without any of the dual licensing bits. It'll also soon have native
    ssl handling for secure log transfer. It's very sexy. I second
    Karanbir's recommendation to take a look at rsyslog.


    --
    During times of universal deceit, telling the truth becomes a revolutionary act.
    George Orwell
  • Mark Weaver at Jan 14, 2008 at 12:38 am

    On Sun, 13 Jan 2008 22:19:51 -0500 "Jim Perrin" wrote:
    On Jan 13, 2008 9:59 PM, Karanbir Singh wrote:

    I recommend rsyslog!
    Well okay, now you've drawn me out!

    I've been playing with rsyslog recently in the hopes of creating the
    'one monitoring server to rule them all' with logging, nagios, ibm
    director, etc. It seems the fedora/rh folks made a very good decision
    in making rsyslog the default logger in fedora 8, but it works equally
    well in centos5 as a drop in replacement for the sysklogd logger. In
    addition to the usual logging you get by default in centos, rsyslog
    also allows for log templating, regex filtering, alerts, tcp and udp
    delivery, logging to database (mysql, but soon postgres) and sane
    multi-host log handling. It's a very good competitor to syslog-ng,
    without any of the dual licensing bits. It'll also soon have native
    ssl handling for secure log transfer. It's very sexy. I second
    Karanbir's recommendation to take a look at rsyslog.
    <grin>

    already downloaded. going to transfer to the web server and start
    reading through the setup docs as soon as Iron Eagle is over.
  • Karanbir Singh at Jan 14, 2008 at 3:35 am

    Jim Perrin wrote:
    without any of the dual licensing bits. It'll also soon have native
    ssl handling for secure log transfer. It's very sexy. I second
    Karanbir's recommendation to take a look at rsyslog.
    am in the process of bringing that into centosplus :D

    --
    Karanbir Singh
    CentOS Project { http://www.centos.org/ }
    irc: z00dax, #centos@irc.freenode.net
  • Ralph Angenendt at Jan 14, 2008 at 10:10 am

    Mark Weaver wrote:
    I personally can think of no reason at all for php-cli.
    php-pear needs it. Why php itself depends on it isn't clear to me
    either.

    Cheers,

    Ralph
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: not available
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: not available
    Url : http://lists.centos.org/pipermail/centos/attachments/20080114/3d350705/attachment.bin
  • Mark Weaver at Jan 14, 2008 at 7:32 pm

    On Mon, 14 Jan 2008 11:10:17 +0100 Ralph Angenendt wrote:

    Mark Weaver wrote:
    I personally can think of no reason at all for php-cli.
    php-pear needs it. Why php itself depends on it isn't clear to me
    either.

    Cheers,

    Ralph

    that in and of itself bothers me.
  • Barry Brimer at Jan 13, 2008 at 7:46 pm

    Even an exteremely brief search of the archives of this list would turn up
    tons of similar questions, and the same answer every time -- Red Hat
    backports security fixes to the stable version of packages in their
    Enterprise distro. That's why, e.g., for it's entire 5 year supported life,
    RHEL5 will be based on kernel 2.6.18. However the base kernel will be
    heavily patched for security, driver upgrades, and new hardware support.
    They treat all packages (including PHP) similarly.
    Red Hat now supports RHEL for 7 years after the release of each version.
  • Santa Claus at Jan 12, 2008 at 8:34 am
    Hi
    When (some) expected rpm package for the upgrade php to version
    5.2.5(CentOS4)
    ?
    ummm ... the answer is probably never.
    It is not clear why Red Hat (and CentOS too), so weak responds to changes of
    important packages.
    In this case the question: how to upgrade to PHP 5.2.5 correctly?

    1. make ... etc.
    2. or go search rpms/rpm in private repositories (for example:
    http://www.jasonlitka.com/2007/11/16/upgrading-to-php-525-on-rhel-and-centos/
    )?

    --
    wbr
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20080112/85bc8873/attachment.htm
  • John R Pierce at Jan 12, 2008 at 8:37 am

    Santa Claus wrote:
    It is not clear why Red Hat (and CentOS too), so weak responds to
    changes of important packages.
    In this case the question: how to upgrade to PHP 5.2.5 correctly?
    If its really not clear, you're totally missing the whole *point* of RHEL.
  • Santa Claus at Jan 13, 2008 at 6:53 pm
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?

    --
    wbr
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20080113/54661df9/attachment.htm
  • Jim Perrin at Jan 13, 2008 at 7:19 pm

    On Jan 13, 2008 1:53 PM, Santa Claus wrote:

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    There is no "correct" method for this, there are only "less wrong"
    ways to do it.
    1. download form php.net + make ... etc.
    No. This method is not advisable at all, because it circumvents the
    package management of the system. This point stands for every distro
    with a package manager, not just centos.
    2. or go search rpms/rpm in private repositories
    You can go this route, however if you do, you'll have to seek some of
    your support from them, as well as trusting them for security updates,
    and proper building. I would really not recommend moving to php 5.25
    at all.

    If you're absolutely dead set on poking the tiger with this particular
    pointy stick, you can get the packages from the atomic rocket turtle
    repository (no I am not making up that name).

    --
    During times of universal deceit, telling the truth becomes a revolutionary act.
    George Orwell
  • Anup Shukla at Jan 14, 2008 at 7:34 am

    Jim Perrin wrote:
    On Jan 13, 2008 1:53 PM, Santa Claus wrote:

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    There is no "correct" method for this, there are only "less wrong"
    ways to do it.
    1. download form php.net + make ... etc.
    No. This method is not advisable at all, because it circumvents the
    package management of the system. This point stands for every distro
    with a package manager, not just centos.
    I think 'make' to something like '/opt/php-5.2.5' would be "less wrong".
    At least that is where i keep my 'make'd apps.

    Suggestions?

    --
    Regards,
    Anup Shukla
  • John R Pierce at Jan 14, 2008 at 8:14 am

    Anup Shukla wrote:
    Jim Perrin wrote:
    On Jan 13, 2008 1:53 PM, Santa Claus wrote:

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    There is no "correct" method for this, there are only "less wrong"
    ways to do it.
    1. download form php.net + make ... etc.
    No. This method is not advisable at all, because it circumvents the
    package management of the system. This point stands for every distro
    with a package manager, not just centos.
    I think 'make' to something like '/opt/php-5.2.5' would be "less wrong".
    At least that is where i keep my 'make'd apps.
    apache has php dependencies, so you'll be replacing that too? and, in
    turn, php has dependencies on dozens of other RPMs, like libraries,
    databases, yada yada. it spirals out.
  • Anup Shukla at Jan 14, 2008 at 1:35 pm

    John R Pierce wrote:
    Anup Shukla wrote:
    Jim Perrin wrote:
    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    There is no "correct" method for this, there are only "less wrong"
    ways to do it.
    1. download form php.net + make ... etc.
    No. This method is not advisable at all, because it circumvents the
    package management of the system. This point stands for every distro
    with a package manager, not just centos.
    I think 'make' to something like '/opt/php-5.2.5' would be "less wrong".
    At least that is where i keep my 'make'd apps.
    apache has php dependencies, so you'll be replacing that too? and, in
    turn, php has dependencies on dozens of other RPMs, like libraries,
    databases, yada yada. it spirals out.
    _______________________________________________
    Yes, i have been bitten by this.
    But at times you are left with no option.
    I *needed* 5.2.x and so had to compile and install
    apache and php both.

    In addition, since php wont compile with the available mysql,
    i had to put a copy (static) of the same.

    And then it was the extensions and a plethora of other things.

    It was more work than what i would like to put in.

    But given the situation that i *must* compile something on my own,
    i think its better to put it in "/opt" or something similar.

    --
    Regards,
    Anup Shukla
  • Mark Weaver at Jan 14, 2008 at 10:42 pm

    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net <http://php.net> + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?
    you can get what you want with this repo info:

    [dag]
    name=Dag RPM Repository for *Red Hat Enterprise Linux*
    baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
    gpgcheck=0
    enabled=1

    Mark
  • Tom G. Christensen at Jan 15, 2008 at 8:05 am

    Mark Weaver wrote:
    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net <http://php.net> + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?
    you can get what you want with this repo info:

    [dag]
    name=Dag RPM Repository for *Red Hat Enterprise Linux*
    baseurl=http://apt.sw.be/redhat/el$releasever/en/$basearch/dag
    gpgcheck=0
    enabled=1
    dag/rpmforge does *NOT* provide php 5.2.x.

    For php 5.2.x on CentOS 4 and 5 I would recommend the "Les RPM de Remi"
    repository at http://remi.collet.free.fr/index.php
    It contains only the bits necessary for php 5.2.x and it's the least
    intrusive repository for php 5.2.5 on CentOS 4 and 5 that I've found.

    -tgc
  • Michael A. Peters at Jan 15, 2008 at 6:38 am

    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net <http://php.net> + make ... etc.
    2. or go search rpms/rpm in private repositories
    I've got them here - but absolutely no support whatsoever.
    http://www.pennywasted.info/centos/yjl.php

    Only for i386 right now.
    It's basically a rebuild of Fedora 8 src.rpm and I track them for
    security patches, but not often (once a month).

    Given you've had insecure apps installed, I would suggest installing the
    suhosin module as well. It may break your apps, but when it does, that's
    usually a good thing (apps it breaks are usually doing things very
    incorrectly).
  • Johnny Hughes at Jan 15, 2008 at 4:20 pm

    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?
    I would personally recommend that you not do it at all ... if you want
    cutting edge and not enterprise software, then CentOS is probably NOT
    the distro that you want to install.

    However, here IS a source of newer PHP and mysql RPMS that I know do
    work and I think will be maintained for a long period of time:

    http://www.jasonlitka.com/

    Thanks,
    Johnny Hughes

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 252 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20080115/1117d078/signature.bin
  • Scott Silva at Jan 15, 2008 at 4:31 pm
    on 1/15/2008 8:20 AM Johnny Hughes spake the following:
    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?
    I would personally recommend that you not do it at all ... if you want
    cutting edge and not enterprise software, then CentOS is probably NOT
    the distro that you want to install.

    However, here IS a source of newer PHP and mysql RPMS that I know do
    work and I think will be maintained for a long period of time:
    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.

    - --
    MailScanner is like deodorant...
    You hope everybody uses it, and
    you notice quickly if they don't!!!!
  • Steven Vishoot at Jan 15, 2008 at 4:50 pm

    --- Scott Silva wrote:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    on 1/15/2008 8:20 AM Johnny Hughes spake the
    following:
    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?
    I would personally recommend that you not do it at
    all ... if you want
    cutting edge and not enterprise software, then
    CentOS is probably NOT
    the distro that you want to install.

    However, here IS a source of newer PHP and mysql
    RPMS that I know do
    work and I think will be maintained for a long
    period of time:
    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.

    - --
    MailScanner is like deodorant...
    You hope everybody uses it, and
    you notice quickly if they don't!!!!
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.3 (MingW32)
    Comment: Using GnuPG with Mozilla -
    http://enigmail.mozdev.org

    iD8DBQFHjN/tRADw9lziUqQRAqhqAJ91kHl7OqzaxJ7VY+kCLQEDagCOkwCfRXNh
    H54hkJBD4GBJL6iOD83s7ok=
    =Ch61
    -----END PGP SIGNATURE-----

    _______________________________________________
    CentOS mailing list
    CentOS@centos.org
    http://lists.centos.org/mailman/listinfo/centos
    Does Having your cake and eating come to mind?
  • Morten Torstensen at Jan 15, 2008 at 9:40 pm

    Steven Vishoot 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.
    Does Having your cake and eating come to mind?
    No, because in this case your cake disappears in thin air as soon as you
    try to eat it. Replacing major components in CentOS really goes against
    the entire idea of an enterprise linux distro. Do it only if you really
    really have to and if you really understand every implication of it.

    You make your apps work on CentOS/RHEL, you don't make CentOS/RHEL work
    with your apps. This is how the enterprise work. The application vendors
    of enterprise grade apps test and develop to the enterprise linux distros.

    I am afraid the analogy police will have to come and arrest you... :)

    //Morten
  • Mark Weaver at Jan 15, 2008 at 5:04 pm

    Scott Silva wrote:
    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    on 1/15/2008 8:20 AM Johnny Hughes spake the following:
    Santa Claus wrote:
    Hi

    Thanks to all who responded.
    But I repeat the question:
    how to upgrade CentOS4 to PHP 5.2.5 correctly?
    1. download form php.net + make ... etc.
    2. or go search rpms/rpm in private repositories
    ?
    I would personally recommend that you not do it at all ... if you want
    cutting edge and not enterprise software, then CentOS is probably NOT
    the distro that you want to install.

    However, here IS a source of newer PHP and mysql RPMS that I know do
    work and I think will be maintained for a long period of time:
    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.
    it's a case of update-itis. In general the Linux community is partially
    responsible due to historical development processes we've all become
    accustomed to, but in most part MS is responsible for getting people to
    believe they need to have the latest and greatest.

    --
    Mark

    "If you have found a very wise man, then you've found a man that at one
    time was an idiot and lived long enough to learn from his own stupidity."
    ==============================================
    Powered by CentOS5 (RHEL5)
  • Bart at Jan 15, 2008 at 6:32 pm

    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.
    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.. ;)

    Cheers,

    Bart
    -------------- next part --------------
    An HTML attachment was scrubbed...
    URL: http://lists.centos.org/pipermail/centos/attachments/20080115/3f36ec58/attachment.htm
  • Johnny Hughes at Jan 15, 2008 at 6:52 pm

    Bart 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.
    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

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 252 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20080115/11134a40/signature.bin
  • Bart at Jan 15, 2008 at 7:03 pm

    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.

    Cheers,

    Bart
  • Johnny Hughes at Jan 15, 2008 at 7:33 pm

    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?id7620

    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,
    Johnny Hughes


    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 252 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20080115/b98aed46/signature.bin
  • Bart at Jan 15, 2008 at 10:09 pm

    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?id7620

    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?

    Cheers,

    Bart
  • Johnny Hughes at Jan 15, 2008 at 10:29 pm

    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?id7620

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 252 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20080115/2cc2562e/signature.bin
  • David Hrbáč at Jan 16, 2008 at 8:49 am

    Johnny Hughes napsal(a):
    Is this what you are talking about???

    http://bugs.php.net/bug.php?id7620

    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,
    Johnny Hughes
    Johnny,
    it doesn't work the way you say. I can name two bugs I consider serious:
    https://bugzilla.redhat.com/show_bug.cgi?id8417
    https://bugzilla.redhat.com/show_bug.cgi?id$3909

    They are long-term bugs with no results. :o(
    Regards,
    David
  • Michael A. Peters at Jan 16, 2008 at 1:02 am

    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.
  • Johnny Hughes at Jan 16, 2008 at 7:53 pm

    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.

    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 252 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.centos.org/pipermail/centos/attachments/20080116/940511d7/signature.bin
  • Michael A. Peters at Jan 17, 2008 at 6:05 am

    Johnny Hughes wrote:
    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.
    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.
  • Morten Torstensen at Jan 17, 2008 at 11:33 am

    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
  • Michael A. Peters at Jan 17, 2008 at 1:05 pm

    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)
  • Michael A. Peters at Jan 17, 2008 at 1:18 pm
    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

Related Discussions

People

Translate

site design / logo © 2020 Grokbase