better management of php-src/pear and PEAR's future in php

Hi, I'd like to start a discussion on php-src/pear and how we can manage it better for PHP 5.3, and to discuss the future of PEAR in PHP. First, take note that both internals@ and pear-dev@ are copied on this email. For some background, currently the pear components are dynamically added to a checkout by downloading from pear.php.net. These components are install-pear-nozlib.phar and go-pear.phar (for windows). In addition, the windows go-pear.phar is only downloaded by the build script for windows. Although this works, it adds some obscurity to how the process really works. I'd like to consider instead using svn:externals to pull in PEAR stuff directly from a STABLE branch from somewhere in the pear/ hierarchy. This would allow us over at PEAR to push the installation phars into that branch at the same time a release is made, and would also allow quick fixes by a quick revert to a previous revision. In terms of the future of PEAR in php-src, now that Pyrus is approaching its first public releases, I'd like to brainstorm how best to replace PEAR when the time is right. Some questions that I have: 1) how important is the backwards compatibility of the "pear" and "pecl" script commands? I.e. does Pyrus need to provide a way to emulate the interface to these scripts or can we break backwards compatibility on this point by having these scripts just call pyrus's frontend with default channels pear/pecl? 2) what about php 6? Any interest in providing Pyrus with php 6? (this is much more long-term hypothetical than the previous question since few of you know anything about pyrus. Pyrus is a PHP 5.3+ re-write of the PEAR installer) Thanks, Greg