Hi Rasmus,

I hope you've got a lot of fingers on your hand, because we do this as well.

All servers are updated with an apt script and our private repository. It's easier to manage a single php package on all servers, that 14 different packages. Each time PHP updates we take the newest packages from pecl and sometimes if PHP isn't updated for a more than a month, we might make a build with the same PHP version but new pecl packages.

To my knowledge this is standard practice for ISP's (who build PHP them selfs). I haven't heard of anyone actually using `pecl update` to update. Most ISP's just update the whole thing one each week, month, year, decade.

Best regards,
Arnold


Rasmus Lerdorf wrote:
Gwynne Raskind wrote:
On Jul 17, 2007, at 3:44 PM, Rasmus Lerdorf wrote:
Hey Jani, nice job on the unknown configure options check.  I saw the
commit go through a couple of days ago, and today it got me to clean up
an ancient build script I have been using for ages when it gave me
this:

Notice: Following unknown configure options were used:

--with-pdflib=/usr/local
--enable-gd-imgstrttf
--with-expat=/usr
--with-xmlreader

Check './configure --help' for available options
This is exactly why I added it. :)

Only side-effect is that any 3rd party extension which happens to use
the AC_ARG_* macros will cause it to report those as "unknown". But
perhaps it's time to be update.. ;)

*cough* APC *cough*
But this check isn't in a phpize-generated configure script, so I don't
see how this is a problem.  The number of people who build pecl
extensions in the main source tree can probably be counted on one hand.
*raises hand* I do... all the time. *crawls back under her rock*

Can you explain why?  I find it much easier to build the non-core stuff
separately so I can update either without affecting the other.

-Rasmus

Reply via email to