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. The pear installer still doesn't work on Windows. We obviously can't approach it the same was as on UNIX since most Windows users are not going to have a compiler available. That means we need to distribute binaries. Not a huge hurdle, but some work needs to be done on this.
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: 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. 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. 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. -Rasmus On Sun, 8 Jun 2003, Sterling Hughes wrote: > On Sun, 2003-06-08 at 12:56, Rasmus Lerdorf wrote: > > On Sun, 8 Jun 2003, Sterling Hughes wrote: > > > I agree 100%. > > > > > > Also, do note that all common extensions will still be direct aliases. > > > Meaning there should be no difference from a development perspective > > > (we'll still have the same set of extensions in cvs, for all practical > > > purposes). The only difference is that when the release manager goes > > > ahead and makes a new release, he'll grab the latest stable release from > > > PECL (which is aliased), instead of using whatever happens to be in CVS. > > > > But if that is the only motivation here, we don't need to move anything, > > we just need developers to tag their extensions when they deem them stable > > and makedist simply checks out the latest stable version of the extension. > > Problem solved. You need a better reason for highly disruptive CVS > > changes. > > > > Problem not really solved. First and foremost, managing two branches is > a lot more error prone then just creating a new release. When you > "only" commit stuff to stable, operations are not entirely atomic and > you don't have proper versioning in place. In order to achieve a > similair result you would need multiple cvs tags, and the rm would have > to choose the right tag. > > This is also the only "current" reason from a "development perspective" > or a "QA perspective." From a user perspective there are other reasons > as well. One of the major ones being the ability to go: > > ]$ pear install mysqli > > Because they (or their sysadmin) forgot to compile PHP with mysqli > support. This only works on UNIX at the moment, but that's 90% of our > userbase that would gain immediate (when PHP5 is released) benefit. > While I think a Win32 port of PEAR/PECL which works as nicely as the > UNIX version is a great idea, its not really a necessity for any of > this. > > The Win32 people, as things stand today, not only decide what extensions > get bundled, but they often decide on a different set than what is > bundled with PHP. Therefore, using PECL, they could even say :: > > ./build-release win32 > > And get the standard set of extensions that would be bundled with > win32. They could further choose extra extensions from PECL, etc. etc. > etc. > > The driving idea is that we have a standard distribution and management > point for all extensions. Its not only for clarity (although that's a > good reason in itself), but it also has practical advantages as well. > Its important that we get the barebones version of this in-place, PECL > needs to become the first class citizen. Then we can go ahead with some > of the more optimistic goals. > > -Sterling > > -- > "A business that makes nothing but money is a poor kind of business." > - Henry Ford > > -- > PHP Internals - PHP Runtime Development Mailing List > To unsubscribe, visit: http://www.php.net/unsub.php > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
