> Many PEAR packages are maintained, and they are globally installed > meaning when a vulnerability is found, there is one to be fixed and > everything on the system is fixed.
Which is great. Practice showed that global PHP packages are not that good actually and managing dependencies on a local level (per project) is much more scalable and overall better, but whatever works for your project. > Composer is like static linking compared to PEAR which is liked shared > linking. Composer can install things globally. I'm not sure I understand why is this even a discussion Composer vs. PEAR core installer script at the moment. The pull request is about disabling the PEAR option. Which I suggest to go further because, for example, waiting for a PHP 10 release for this step is really not a smart move for multitude of reasons... > So what problem is this really solving? Every PEAR issue actually that was caused in the several years. This time it was the each(), next version will be foo()... Not to mention that still there are bugs out there that are really painful to solve. For example, shared core (shipped) PHP extensions and PEAR is a no go without a patch. I mean if there are maintainers, and people who want to keep this PEAR in the php-src repository, fine I guess. But then I'm not sure what can be done here anyway... -- Peter Kokot -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
