Re: solution for those depending on PEAR packages with non-PEAR

Greg Beaver wrote:

Pierre-Alain Joye wrote:

On Thu, 21 Apr 2005 23:11:21 -0400 cellog@php.net (Greg Beaver) wrote:

The installer, on the other hand, would not install the package automatically, but would prompt the user with "This package patches pear.php.net/Foo version 1.2.0 from uri http://www.example.com/Foo-1.2.0.1.tgz because of Critical Bug in Bar(), do not install unless you trust this source. Install? [Y]"

This is an ugly solution to a common problem. If one realized than a package is not maintain, the authors do not want to add a vital (for him) feature or whatever, he can create its own (based on the old or not) and add it to his channel. The problem is then fixed, without confusion or upcoming conflicts.

The problem is not fixed. If you use the same directory structure, the new package will conflict with the PEAR package, and users won't be able to have both installed at once. If you change the directory structure, you have to modify every instance in your application. In addition, the instant you start maintaining your own private copy, you lose all of the benefits of open source, and we're back to caveman programming again.

which is what i amd doing now

In the real world, if there is no way to provide a quick patched version, then you simply can't depend on the package at all, which means you can't use the PEAR installer at all, and you might as well not use PEAR at all, and just maintain private forks of PEAR packages. We really need a better solution than "just keep doing what you're doing, it's not our problem" in this case. That is, unless PEAR really is useless. If that's the case, then I think we need to talk :).

the point is that a maintainer of a package needs to make sure that changes and additions make sense for all possible uses, whereas as user of a package only has to ensure that fixes or changes make sense for their use. this gives users often a much easier way to solve issues as they occur compared to the maintainer, especially if the issue was discovered by that user. regards, Lukas