Re: pear installer in PHP 5.1 RC1

cross-posting because this involves all PEAR developers, and feedback is probably warranted on this debate in order to make the best decision. Pierre-Alain Joye wrote: >On Thu, 11 Aug 2005 11:40:37 -0700 >papercrane@gmail.com (Justin Patrin) wrote: > > > > >>So that it can have its own release cycle. >> >> > >And it adds again a dep to PEAR. It's a pain to keep an eye on each >dep, or we did not do it at all for one or another (last in date, >xmlrpc). > >The goal is to have no dep at all (if possible though :) but php >extensions. So moving ErrorStack (one file!!) in its own package >for the beauty of the gest or to have its own releases is not the >best idea one can have, in my opinion. > I have written about this in the past, but never very clearly. There is a basic misunderstanding about the purpose of the PEAR installer going on here and I would like to clear this up as soon as possible. Let's examine some assumptions: 1) dependencies are bad 2) it's impossible to track external packages #1 is a very interesting assumption. Let me rephrase what this assumption really says: 1) the primary purpose of the PEAR installer is bogus The *only* thing the PEAR installer does that is better than simple unzip-and-install is manage dependencies. In the past versions of PEAR, it did this rather terribly, allowing upgrades to BC-breaking releases of dependencies such as Console_Getopt and so on. This problem is fixed with the <compatible> tag. Releases can be made of a package that will NOT automatically be upgraded by any user, allowing testing and proper configuring/fixing prior to making the dependency compatible. The act of avoiding dependencies results in bloated, ridiculously large extraneous stuff in packages, which also defeats the primary strength of PEAR: the ability to quickly release a fixed package without having to redundantly release everything in the package. #2 is not true either, but I do have a proposal for the future that will guarantee this: All dependencies in PEAR must be fully accessible to all PEAR lead developers. In other words: 1) PEAR package leads should have full authority to fix bugs in deps like Console_Getopt/Archive_Tar 2) PEAR package leads should have full authority to release/pull releases for dependencies. PEAR will much better serve the community if modularity works properly. I don't see how the XML_RPC dep was "not tracked," this is simply a case of bugs in a dependency that would most likely be there if we simply stripped the code and put it into PEAR itself. This is why we have dependencies in the first place, so that community scrutiny can find more bugs and enhance the features. I'm afraid I'm out of time (Concert in 35 minutes) but I hope this helps to clarify my views on the issue. Greg