Re: pear installer in PHP 5.1 RC1

Pierre-Alain Joye <pierre@dotgeek.org> wrote: > It is the most valid argument. Have you a single idea how many > (silent) people relies on PEAR? and the files installed? Yes. As I said before, a required dependency on a package that installs a file that is compatible with previous releases of ErrorStack in the exact same location does nothing to worry any of those many silent people. Or the vocal ones, for that matter, despite what they may say while vocalizing. The BC breakage issue is a non-issue, Pierre. As I said before, it is simply not a valid argument. If you still feel that it is valid, please describe a scenario in which a BC break would occur. Consider that ... Before splitting PEAR_ErrorStack into its own package, PEAR core looks like this: [php_dir]/ PEAR.php PEAR/ ... ErrorStack.php ... After splitting PEAR_ErrorStack into its own package, and making it a required dependency for the PEAR installer, PEAR core looks like this: [php_dir]/ PEAR.php PEAR/ ... ErrorStack.php ... ... Where's the BC break? I would really like to understand what the argument is FOR the BC break, because either none exists, or I have a terminal misunderstanding of how the installer behaves in regard to dependencies. > Reducing the dependencies is all about improve the quality and the > control of the release process. The past prooved that more deps > only introduce more troubles. If you do not believe that, check the > various list archives and bugs. If I understand this statement correctly, the future of PEAR core depends entirely on the outcome of past mistakes? No consideration is to be given in the future to current events -- only the past matters? That's a scary line of thinking, Pierre. Isn't PEAR itself about reusable code, a concept made possible by smaller, specialized independent packages? I am honestly at a total loss of understanding why the idea of splitting PEAR_ErrorStack out is this big of a deal. I'm not talking about splitting out ANY part of the PEAR core -- I am not talking about zillions of future dependencies, etc. etc. Nor am I talking about past dependency problems, or the recent XML_RPC package issues. I'm talking specifically about splitting out PEAR_ErrorStack, given its history and what I understand of the desire of the current primary developer of BOTH PEAR Core and PEAR_ErrorStack. Why is this, specifically, a problem? I want to understand if there's a real issue with this specific scenario, because it's truly not my goal to just argue for arguing's sake. -Clay -- Killersoft.com