"Rasmus Lerdorf" <[EMAIL PROTECTED]> > I know the reasoning, but you were discounting everything except the > versioning which I simply pointed out could be done without the move just > as effectively. PECL's versioning support is no better than what can be > done directly with CVS.
There is already support for: 'alpha','beta','stable','snapsho t','devel' package states, plus all the version number formats supported by version_compare(). IMHO that's more than enough. > The pear installer still doesn't work on Windows. I you mean the pear installer, it do work on Windows since many time. If you mean the build of extensions, AFAIR, Shane did it. Take a look at: php4/pear/PEAR/Builder.php. Don't know if works or not, but the code is there. > We also need to work more on the UNIX pear installer. For example, take > your zip extension. Joe Average user who tries to install it sees: The good news is that even Joe Dumb, could use it. > 10:27am thinkpad:~> pear install zip > downloading zip-1.0.tgz ... > ...done: 4,930 bytes > 3 source files, building > running: phpize > PHP Api Version : 20020918 > Zend Module Api No : 20020429 > Zend Extension Api No : 20021010 > building in /var/tmp/pear-build-root/zip-1.0 > running: /tmp/tmpaIv3b4/zip-1.0/configure > `/tmp/tmpaIv3b4/zip-1.0/configure' failed > > And no info at all on why exactly it failed and that temp build dir is > gone. We need to keep the configure output in case of failure. Or even > better, if we could somehow pull the external dependencies from the > config.m4 and add them to the package.xml and have that dependency check > run early on so people got a message right up front that they don't have > the required 3rd party libraries a given PECL package requires. This sounds cool, but perhaps you are not informed on what dependecy pre-checking PEAR already has (currently: package, extension, program, os, php version, sapi, zend). External lib checking could be easily implemented as well. There is a discussion already at pear-dev on building tools to help developers the creation of the package.xml file (along other helper tools like unit tests or api doc generation). > Of course, a -v reveals: > > ... > checking for ZIP support... yes, shared > configure: error: Cannot find libzzip > `/tmp/tmp42WFky/zip-1.0/configure' failed > > So it makes sense that it failed, but if we pushed this out in its current > state we would spend the next year telling people to add -v and asking for > the output. Hehe, can't beleive it, you just needed to write pear-dev and I'll commit the 1 line patch needed to support that. > Basically my point is that instead of pushing extensions into the current > void that is PECL, we need to pull PECL from the void and make it work > first. You seem to want to take the reverse approach. Push everything > into PECL and by doing that force someone to fix it, versus fixing PECL > and then having people fall over themselves trying to get their extensions > into this new brilliant framework. Basically my point is that PECL is not going to have any success or use, if you don't say what you need for PECL, and first of all: to give it a chance. We were focusing on PEAR packages because is what we use and because none told us any feature request or bug report for PECL. The other day, Sterling came to IRC: "hey Tomas, I need a pear bundle command", in 4 hours he got it. Tomas V.V.Cox -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
