Thinking a bit about this topic, I thought I'd pen some thoughts as to why bother moving to PECL in the first place, just to put things into perspective.
As an extension developer, PECL provides the following: -- your own release cycles. -- granular package management : want to be the only maintainer? Fine, this is no problem with PECL. As well as the other sourceforge-esque things that will come as people request them. As an end user (and dev), PECL provides the following: -- easier install path. (# pear install foo) -- no need to recompile... Useful in hosting environments where you may have chrooted apache/php.. This doesn't sound like much, however I think it's quite substantial, as it allows extension developers to provide different release cycles to the main php core. What does that mean for the PHP RM? -- less QA hassle. The only releases that would get sent out via a PHP RM would be <ext>-<version>-STABLE.tgz -- or in other words, packages that would have had, theoretically, a substantial amount of QA already, and so would require less attention from the PHP RM. That means that QA can focus on core language issues. -- smaller packages. We can provide php-lite, php-all, php-common packages. Php-lite would just incorporate the main core of php, and the pear/pecl tools. Php-all would be a complete bundle, with suggested libraries included, and php-common would be like php.ini-recommended. How do we get here? By moving PECL into the limelight. This week, I will be splitting PECL into it's own cvs module, and (after discussion) I'd like to create a version of pearweb for pecl.php.net, essentially seperating the PEAR and PECL projects. We can then start an upgrade path of getting packages into PECL. I am pretty sure that doing this kind of stuff will make life easier for our downstream users (ie, cc'ed Joe Orton, who packages RPMs for RedHat) as they more or less do this _already_ anyhow. We will (hopefully) make it easier for them so they can remove their hacks to do this. I think the feeling of throwing everything into PECL right now is probably flawed; as Rasmus said, we are at risk of forcing it to be something it's not right now, and I think this contravenes Stig's excellent management of PEAR (ie, do it right, don't hack it). So, the summary: Lets promote PECL somewhat. Lets make it work without all the minor problems right now (eg, secure binaries, win32 support, etc etc). Then once we are all using that instead of recompiles every time.. (which won't take long) moving to PECL becomes a natural progression. -- james -- James Cox :: [EMAIL PROTECTED] :: http://imajes.info/ Was I helpful? http://www.amazon.co.uk/exec/obidos/wishlist/23IVGHQ61RJGO/ The mind leads, the emotions follow. - Ayn Rand -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
