I agree but it'll take time to build this infrastructure. In the meanwhile I suggest the first step is moving the non-core stuff into PECL once the ./pecl-list and ./pecl-download scripts exist and ./configure has a message pointing users at ./pecl-list (or ./pecl-help :)
Andi At 17:35 25/05/2002 +0300, Zeev Suraski wrote: >As I told Stig yesterday, I think the main problem with PECL right now is >that when an extension is moved to PECL, its author gets the feeling as if >it was banished to Siberia, and that has to be changed. > >I think that the moving of extensions to PECL was supposed to address the >problem of synchronizing the development schedule of a large number of >extensions with the development schedule of PHP itself. There's validity >in this point, and thus, certain extensions would indeed be better off in >PECL. However, that shouldn't necessarily affect their existence in the >PHP distribution - I think this has been discussed before. An extension >CAN reside in PECL and yet, be included in the PHP distribution. One >should not have anything to do with the other. > >When a PHP release (or RC) is packaged, there should be a list of PECL >extensions that do make it into the release. The packager should have a >list of those, and there should be some sort of an easy way for him to >import the latest *stable* version of the extension. That way, >non-esoteric PECL'd extensions do get to have their own release cycle >while still being included in the PHP distribution. > >Zeev > >At 17:24 25/05/2002, Andi Gutmans wrote: >>Hey guys, >> >>I just want to air my opinion on what happened with msession and PECL. >>Although I have not always liked Mark's attitude in the past when it came >>to coding conventions I do think that the move of msession into PECL >>without consulting him nor php-dev was extremely wrong. >>I personally don't hang around on IRC (no time) and the only mailing list >>I follow closely is php-dev. I think that in general it has always been >>an informal agreement that php-dev is the place to take such issues. >>Now about the matter itself. I think one of the main benefit's of PHP >>over the years is that it was very easy for users to get started. A >>single download includes most extensions which are needed to develop web >>applications. I don't think we should change this drastically meaning >>that all *important* and main-stream extensions should stay in the core >>including most of the SQL extensions, XML, XSLT, sessions, COM, bz2, >>zlib, imap, gd, curl and so on. >>I am aware that some of the extensions such as ircg, readline, fribidi >>can be considered not very main stream and it does make sense to move >>some of these into PECL. (I intentionally didn't mention where I think >>msession belongs because that's not what I want to discuss in this Email). >>I do feel that the main problem with PECL is that the only PHP users who >>seem to know about it are people on the PEAR mailing list. I think if >>you'll ask the average PHP programmer and ask him if he knows what PECL >>is he'll have no idea. All he knows is the .tar.gz he downloads from php.net. >>A long time ago I mentioned here that in order for me to support PECL >>we'd have to make sure it is well advertised and it has to make it >>extremely easy to download and install PECL extensions. I was thinking of >>possibly a message at the end of ./configure mentioning that some >>extensions can be gotten from PECL and an automatic way of listing PECL >>extensions and downloading/building them into PHP. >>My idea was something like the following: (From php4/) >>./pecl-list <-- This would give a list and short description of all >>extensions in PECL >>./pecl-download FooBar <-- This would download FooBar and put it in ext/ >>and run ./buildconf >>Then the user could just run ./configure and configure with the >>downloaded extension. Most users still prefer to statically build their >>extensions and not use phpize although that could be optional. >> >>Once we have this kind of mechanism I think it'll be much easier for us >>to move non-core extensions into PECL. As I mentioned before I still >>think that the traditional core extensions should stay in the main PHP >>distribution. PHP in embedded systems is rare and it's no excuse to >>remove core extensions from PHP. People who want to build a naked PHP for >>embedded systems can ./configure PHP accordingly! >> >>My 2 cents. >> >>Andi >> >> >>-- >>PHP Development Mailing List <http://www.php.net/> >>To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Development Mailing List <http://www.php.net/> To unsubscribe, visit: http://www.php.net/unsub.php
