Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:104017 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 86003 invoked from network); 2 Feb 2019 12:46:43 -0000 Received: from unknown (HELO mail4.serversure.net) (185.153.204.204) by pb1.pair.com with SMTP; 2 Feb 2019 12:46:43 -0000 Received: (qmail 23858 invoked by uid 89); 2 Feb 2019 09:27:03 -0000 Received: by simscan 1.3.1 ppid: 23850, pid: 23855, t: 0.0377s scanners: attach: 1.3.1 clamav: 0.96/m:52/d:10677 Received: from unknown (HELO ?10.0.0.7?) (lester@lsces.co.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 2 Feb 2019 09:27:03 -0000 To: internals@lists.php.net References: <7a909cd3-5d0f-8f2e-fba8-009778311bf0@php.net> <77f41814-bb27-bdf0-44d3-d59b64de7d45@librelamp.com> Message-ID: Date: Sat, 2 Feb 2019 09:27:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Disable PEAR by default From: lester@lsces.co.uk (Lester Caine) On 02/02/2019 02:10, Peter Kokot wrote: >> 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... Previously Composer has been pushed as the alternative to using PEAR to maintain third party add-ons. If you disable PEAR then there needs to be an alternative way to provide similar functionality. The NICE thing about PEAR is that it can be managed either by pulling the global packages as in the case of say Horde or one can bundle the same packages locally while maintaining local tailoring of those packages. That you don't understand why they are being linked is perhaps part of the whole problem? Legacy projects CAN at least pull copies of the key third party PEAR packages without the problem of someone else messing them up. Yes the likes of each() screwing things up is a problem and is all part of the agro introduced by deprecating code that is currently working safely and securely, but it is a lot easier to patch that in a PEAR based system than in composer based ones until official patches filter through. Simply trying to rebuild systems heavily reliant on one to work with the other is yet another drain on limited resources. -- Lester Caine - G8HFL ----------------------------- Contact - https://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - https://lsces.co.uk EnquirySolve - https://enquirysolve.com/ Model Engineers Digital Workshop - https://medw.co.uk Rainbow Digital Media - https://rainbowdigitalmedia.co.uk