Hi, On Fri, Oct 10, 2025 at 2:44 PM Brent Roose <[email protected]> wrote:
> The only thing related to PHP/internals is the fact PEAR is bundled with >> PHP and that the PEAR website is a subdomain pear.php.net. >> > > In my opinion, this is sufficient reason to have an RFC for it. A quick > search through the RFCs showed a handful of website-related ones: > > - https://wiki.php.net/rfc/deprecate-pear-include-composer > - https://wiki.php.net/rfc/global_login > - https://wiki.php.net/rfc/phpnet-analytics > > Then there's the fact that Pear comes bundled with PHP, even more of an > argument that internals have at least something to say about it. Several > RFCs have addressed bundling/unbundling third party plugins before. Again, > a quick search: > > - https://wiki.php.net/rfc/unbundle_imap_pspell_oci8 > - https://wiki.php.net/rfc/unbundle_xmlprc > - https://wiki.php.net/rfc/deprecate-and-remove-ext-wddx > - https://wiki.php.net/rfc/unbundle_recode > > To me, and I believe to a significant part of the PHP community, what's > most important is for PHP to acknowledge that composer is its de-facto > standard package manager. This doesn't mean composer cannot operate > independently anymore, but an endorsement would make a lot of sense. > Removing PEAR/PECL from php-src is absolutely fine and such RFC should be done. As I mentioned, we could also discuss removal from the php.net domain (move it to the separate domain from pear.php.net). That's what we control and can do. But that is not what was proposed in this RFC. It was proposing deprecating PEAR site and the tool which is quite different. Because this is maintained outside PHP GitHub organization: https://github.com/pear and from what I understand even the servers hosting the website are not maintained by us. But this is just my understanding and maybe I'm missing something and that's why I asked for people with access to comment here because without them, such RFC is pointless. Kind regards, Jakub
