Everything
php
Learn Community Releases The PHP Project
Home » Project » Newsgroups » php.internals » [RFC] [Discussion] Deprecate PEAR and recommend Composer »

[RFC] [Discussion] Deprecate PEAR and recommend Composer

php.internals

James Titcumb

327 days ago
Folks, Presenting the RFC for deprecating PEAR and recommending Composer as the recommended PHP package installer: https://wiki.php.net/rfc/deprecate_pear_recommend_composer Plan to move to vote on or shortly after 24th October all being well. Thanks James

Christoph Becker

326 days ago
On 09.10.2025 at 12:28, James Titcumb wrote:
> Presenting the RFC for deprecating PEAR and recommending Composer as the > recommended > PHP package installer: > > https://wiki.php.net/rfc/deprecate_pear_recommend_composer > > Plan to move to vote on or shortly after 24th October all being well.
Apparently, this RFC has been withdrawn in the meantime. I would like to know why. :) Christoph

James Titcumb

326 days ago
On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote:
> Apparently, this RFC has been withdrawn in the meantime. I would like > to know why. :)
I absolutely agree with you - a discussion took place on the PHP Foundation slack. I raised a concern that it should be discussed here on the list for transparency. I am frustrated that it was not. The short version of that discussion is that PEAR is maintained by someone else; the PEAR group apparently is separate from the PHP group, as I understand it. 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. I withdrew the RFC because it seems this is a can of worms. On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker <cmbecker69@gmx.de> wrote:

Pierre Joye

326 days ago
Hi James, On Fri, Oct 10, 2025, 3:29 PM James Titcumb <titcumbjames@gmail.com> wrote:
> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote: > >> Apparently, this RFC has been withdrawn in the meantime. I would like >> to know why. :) > > > I absolutely agree with you - a discussion took place on the PHP > Foundation slack. I raised a concern that it should be discussed here on > the list for transparency. I am frustrated that it was not. > > The short version of that discussion is that PEAR is maintained by someone > else; the PEAR group apparently is separate from the PHP group, as I > understand it. >
I don't remember the reason back then but it was basically maintained by core devs at some point, including myself. I also wanted to propose that long ago but the composer's team disagree as they wanted to remain fully independent. It may still be the case (you surely ask them). also given there is PIE now, this was theast reason to keep pear/pecl installer around, suggesting to use composer/pie cannot hurt and keep composer independent. a removal/fade it way could be a future next step.

Jakub Zelenka

326 days ago
Hi, On Fri, Oct 10, 2025 at 12:01 PM Pierre Joye <pierre.php@gmail.com> wrote:
> Hi James, > > On Fri, Oct 10, 2025, 3:29 PM James Titcumb <titcumbjames@gmail.com> > wrote: > >> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote: >> >>> Apparently, this RFC has been withdrawn in the meantime. I would like >>> to know why. :) >> >> >> I absolutely agree with you - a discussion took place on the PHP >> Foundation slack. I raised a concern that it should be discussed here on >> the list for transparency. I am frustrated that it was not. >> >> The short version of that discussion is that PEAR is maintained by >> someone else; the PEAR group apparently is separate from the PHP group, as >> I understand it. >> > > > I don't remember the reason back then but it was basically maintained by > core devs at some point, including myself. > >
Is that still the case though? I don't think that any current core developer has access to their GH organizattion. Or do you still have access / control to do any changes there and make it deprecated? My main issue with this RFC is that it's about project that we don't effectively control and I'm not sure here is anyone who can make any such change to it. From what I see it's currently maintained by Chuck who, I guess, also control the project. Or am I wrong? Alternatively we could potentially propose here move that away from the PHP domain if we think it's not good for PHP image but that could mean that we might completely shut it down without any deprecation if there is no agreement with the current maintainers. So the ideal case would be to put together some plan how to either get it deprecated and moved away. But for that we need to first here from the current maintainers and get them on board. If here is anyone who has access to PEAR and can comment on this, that would be great! I also CC'd Chuck as I think it's crucial to get his opinion on this. Kind regards, Jakub

Brent Roose

326 days ago
> > 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. Brent On Fri, Oct 10, 2025 at 12:39 PM Jakub Zelenka <bukka@php.net> wrote:

Jakub Zelenka

326 days ago
Hi, On Fri, Oct 10, 2025 at 2:44 PM Brent Roose <brent.roose@jetbrains.com> 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

Jakub Zelenka

326 days ago
On Fri, Oct 10, 2025 at 2:58 PM Jakub Zelenka <bukka@php.net> wrote:
> Hi, > > On Fri, Oct 10, 2025 at 2:44 PM Brent Roose <brent.roose@jetbrains.com> > 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. >
I just gave it an initial try and it's a bit more involved but should be doable: https://github.com/php/php-src/pull/20124 . Kind regards, Jakub

Derick Rethans

323 days ago
On Fri, 10 Oct 2025, Jakub Zelenka wrote:
> Hi, > > On Fri, Oct 10, 2025 at 2:44 PM Brent Roose <brent.roose@jetbrains.com> > 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.
I think these would be my primary actions too: - unbundle pear/pecl from PHP alltogether - not have pear.php.net on the php.net domain. The latter is because we have no access, and I have no idea what OS it runs, how it is set up, and whether it even received package and OS updates in the last decade. Then somebody else can decide later whether they want to abandon PEAR (and it's new hosted website). cheers, Derick
-- https://derickrethans.nl | https://xdebug.org | https://dram.io Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support mastodon: @derickr@phpc.social @xdebug@phpc.social

Pierre Joye

322 days ago
Hi Derick, On Tue, Oct 14, 2025, 1:05 AM Derick Rethans <derick@php.net> wrote:
> > I think these would be my primary actions too: > > - unbundle pear/pecl from PHP alltogether > - not have pear.php.net on the php.net domain. > > The latter is because we have no access, and I have no idea what OS it > runs, how it is set up, and whether it even received package and OS > updates in the last decade. >
It was migrated, if my memory serves me correctly, at the same time than wiki when the compromising attack happened (long ago). I thought you were involved to it with Bjori? but it may get lost down the road? I lost all pear/pecl/wiki systems accesses during that time. My only wish is if we could keep it archived, read-only, and the pgz accessible as file downloads. That could be done without access tho, but it requires some more work :) best, Pierre

Rowan Tommins [IMSoP]

322 days ago
On 13 October 2025 19:01:15 BST, Derick Rethans <derick@php.net> wrote:
>I think these would be my primary actions too: > >- unbundle pear/pecl from PHP alltogether >- not have pear.php.net on the php.net domain. > >The latter is because we have no access, and I have no idea what OS it >runs, how it is set up, and whether it even received package and OS >updates in the last decade. > >Then somebody else can decide later whether they want to abandon PEAR >(and it's new hosted website).
I'm not sure whether existing installations would recognise a new domain as the same "channel", even with HTTP redirects in place. So moving to a new domain might be equivalent to shutting down the default channel immediately. And that implies that there is someone out there interested enough in running a new channel, and from the evidence I've seen that seems unlikely. Maybe I'm wrong, and if we CC a couple of mailing lists, someone will step up; but if not, I think it's perfectly reasonable for the PHP project (i.e. this list) to step in and shut the project down with some reasonable amount of notice. I don't think we'll do anyone any favours by taking control just long enough to make some config and text changes that disclaim responsibility, then leave any mess to an imaginary "someone else". Rowan Tommins [IMSoP]

Sebastian Bergmann

318 days ago
Am 13.10.2025 um 20:01 schrieb Derick Rethans:
> I think these would be my primary actions too: > > - unbundle pear/pecl from PHP alltogether > - not have pear.php.net on the php.net domain. > > The latter is because we have no access, and I have no idea what OS it > runs, how it is set up, and whether it even received package and OS > updates in the last decade. > > Then somebody else can decide later whether they want to abandon PEAR > (and it's new hosted website).
+1

Pierre Joye

316 days ago
Hi, On Tue, Oct 14, 2025 at 1:05 AM Derick Rethans <derick@php.net> wrote:
> > On Fri, 10 Oct 2025, Jakub Zelenka wrote: > > > Hi, > > > > On Fri, Oct 10, 2025 at 2:44 PM Brent Roose <brent.roose@jetbrains.com> > > 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.
I checked the archives to see who had and may still have access, I found one discussion about compromised pear phar in 2019. It looks like Christian Weiske Chuck Burgess May have access. And eventually Rasmus? I added them to the loop here, let see. That may help doing whatever we decide to do.
-- Pierre @pierrejoye | http://www.libgd.org

Rowan Tommins [IMSoP]

316 days ago
On 20/10/2025 05:22, Pierre Joye wrote:
> I checked the archives to see who had and may still have access, I > found one discussion about compromised pear phar in 2019. It looks > like > > > Christian Weiske > Chuck Burgess > > May have access. And eventually Rasmus? > > I added them to the loop here, let see. That may help doing whatever > we decide to do.
For the record, I posted a message on Saturday, inviting comments on this discussion, to four mailing lists (pear-general, pear-dev, pear-core, and pear-webmaster) plus the pear-group@ address. So far, there have been no responses.
-- Rowan Tommins [IMSoP]

Pierre Joye

325 days ago
On Fri, Oct 10, 2025 at 5:36 PM Jakub Zelenka <bukka@php.net> wrote:
> > Hi, > > On Fri, Oct 10, 2025 at 12:01 PM Pierre Joye <pierre.php@gmail.com> wrote: >> >> Hi James, >> >> On Fri, Oct 10, 2025, 3:29 PM James Titcumb <titcumbjames@gmail.com> wrote: >>> >>> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote: >>>> >>>> Apparently, this RFC has been withdrawn in the meantime. I would like >>>> to know why. :) >>> >>> >>> I absolutely agree with you - a discussion took place on the PHP Foundation slack. I raised a concern that it should be discussed here on the list for transparency. I am frustrated that it was not. >>> >>> The short version of that discussion is that PEAR is maintained by someone else; the PEAR group apparently is separate from the PHP group, as I understand it. >> >> >> >> I don't remember the reason back then but it was basically maintained by core devs at some point, including myself. >> > > Is that still the case though?
For the packages repositories hosted (git, ex-svn),yes, see https://github.com/pear. The idea of the group was to be able to take over abandoned but widely used packages, define what licenses are allowed and other related areas. The packages repositories not hosted on php's repos are still where they used to be, if the service still exists. I checked my archives. For the record, it was done this way as there were strong arguments, and opinions, about php being only about the language itself and nothing else, etc. Things change here and there.
> I don't think that any current core developer has access to their GH organizattion. Or do you still have access / control to do any changes there and make it deprecated? My main issue with this RFC is that it's about project that we don't effectively control and I'm not sure here is anyone who can make any such change to it. From what I see it's currently maintained by Chuck who, I guess, also control the project. Or am I wrong?
I do have access, I did not check the role tho'.
> Alternatively we could potentially propose moving that away from the PHP domain if we think it's not good for PHP image but that could mean that we might completely shut it down without any deprecation if there is no agreement with the current maintainers.
I don't see a point in moving the DNS entry away, that makes little sense. A few steps toward shutdown permanently, once or if agreed to: 1. mail the pear-dev ML and maintainers about the plan 2. disable any new releases, some are still released (f.e.https://pear.php.net/package/Log/) 3. add (future) service shutdown to the pear home page and/or in the site header 4. archive releases somewhere (static's php.net maybe?) 5. Once shutdown's date is reached, static page with link to the archive for the releases (for the few people still using them) The removal for php's dists is obviously a good first step but I would not do it in minor releases tho'. I have seen internal projects here and there still running (php8 too :), and using pear, let's give them a last bit of time to see the light maybe? As of pecl, the same could be applied. I do not know for PIE, but if needed, pickle has the code to migrate package(1|2).xml, target needs to be changed then to what PIE uses now, that's something maintainers of exts can do. Unmaintained ones can go to the archives as well. best,
-- Pierre @pierrejoye | http://www.libgd.org

Rowan Tommins [IMSoP]

325 days ago
On 11 October 2025 10:32:26 BST, Pierre Joye <pierre.php@gmail.com> wrote:
>For the packages repositories hosted (git, ex-svn),yes, see >https://github.com/pear. The idea of the group was to be able to take >over abandoned but widely used packages, define what licenses are >allowed and other related areas. The packages repositories not hosted >on php's repos are still where they used to be, if the service still >exists.
An additional point worth noting is that all the packages in that GitHub org are published to both PEAR and Packagist. A few may not have been tested in Composer projects, but fixes are likely to be easy as long as someone's available to tag a new release - I seem to remember raising a small PR to fix some autoloading or dependency issues for something I needed. For users not ready to adopt a full Composer per-project workflow, we could recommend to use its global install mode, e.g. Replace: pear install HTML_Template_IT With: composer global install pear/html_template_it Then all that should need fixing is include paths or autoloader setup in the application. Rowan Tommins [IMSoP]

Jakub Zelenka

324 days ago
Hi, On Sat, Oct 11, 2025 at 11:32 AM Pierre Joye <pierre.php@gmail.com> wrote:
> On Fri, Oct 10, 2025 at 5:36 PM Jakub Zelenka <bukka@php.net> wrote: > > > > Hi, > > > > On Fri, Oct 10, 2025 at 12:01 PM Pierre Joye <pierre.php@gmail.com> > wrote: > >> > >> Hi James, > >> > >> On Fri, Oct 10, 2025, 3:29 PM James Titcumb <titcumbjames@gmail.com> > wrote: > >>> > >>> On Thu, 9 Oct 2025 at 21:39, Christoph M. Becker wrote: > >>>> > >>>> Apparently, this RFC has been withdrawn in the meantime. I would like > >>>> to know why. :) > >>> > >>> > >>> I absolutely agree with you - a discussion took place on the PHP > Foundation slack. I raised a concern that it should be discussed here on > the list for transparency. I am frustrated that it was not. > >>> > >>> The short version of that discussion is that PEAR is maintained by > someone else; the PEAR group apparently is separate from the PHP group, as > I understand it. > >> > >> > >> > >> I don't remember the reason back then but it was basically maintained > by core devs at some point, including myself. > >> > > > > Is that still the case though? > > For the packages repositories hosted (git, ex-svn),yes, see > https://github.com/pear. The idea of the group was to be able to take > over abandoned but widely used packages, define what licenses are > allowed and other related areas. The packages repositories not hosted > on php's repos are still where they used to be, if the service still > exists. > > I checked my archives. For the record, it was done this way as there > were strong arguments, and opinions, about php being only about the > language itself and nothing else, etc. Things change here and there. > >
Ok so I guess the current status is kind on unknown... :) But as noted by Rowan in other email, there's a mention of the PEAR Group that is the governing body of the project although seems expired so I have really no idea what the governance there is and if the RFC process should have any power over that project.
> I don't think that any current core developer has access to their GH > organizattion. Or do you still have access / control to do any changes > there and make it deprecated? My main issue with this RFC is that it's > about project that we don't effectively control and I'm not sure here is > anyone who can make any such change to it. From what I see it's currently > maintained by Chuck who, I guess, also control the project. Or am I wrong? > > I do have access, I did not check the role tho'. > >
I guess this is really the crucial part here. Are you able / willing / comfortable to potentially update the website or the tool if we approve the RFC about deprecation and are you sure that the current maintainer is ok with that (basically respect RFC as the governance method for PEAR)?
> > > Alternatively we could potentially propose moving that away from the PHP > domain if we think it's not good for PHP image but that could mean that we > might completely shut it down without any deprecation if there is no > agreement with the current maintainers. > > I don't see a point in moving the DNS entry away, that makes little > sense. A few steps toward shutdown permanently, once or if agreed to: > > 1. mail the pear-dev ML and maintainers about the plan
2. disable any new releases, some are still released
> (f.e.https://pear.php.net/package/Log/) > 3. add (future) service shutdown to the pear home page and/or in the > site header > 4. archive releases somewhere (static's php.net maybe?) > 5. Once shutdown's date is reached, static page with link to the > archive for the releases (for the few people still using them) > >
Ok but this assumes that we are able to do 2 and 3.
> > The removal for php's dists is obviously a good first step but I would > not do it in minor releases tho'. I have seen internal projects here > and there still running (php8 too :), and using pear, let's give them > a last bit of time to see the light maybe? >
If we are talking just about removing everything in php-src, then I don't think it's issue to get rid of it in 8.6 but we should for sure have RFC to decide it. Kind regards Jakub

Pierre Joye

324 days ago
On Sun, Oct 12, 2025 at 2:13 AM Jakub Zelenka <bukka@php.net> wrote:
> Ok so I guess the current status is kind on unknown... :) But as noted by Rowan in other email, there's a mention of the PEAR Group that is the governing body of the project although seems expired so I have really no idea what the governance there is and if the RFC process should have any power over that project. > >> > I don't think that any current core developer has access to their GH organizattion. Or do you still have access / control to do any changes there and make it deprecated? My main issue with this RFC is that it's about project that we don't effectively control and I'm not sure here is anyone who can make any such change to it. From what I see it's currently maintained by Chuck who, I guess, also control the project. Or am I wrong? >> >> I do have access, I did not check the role tho'. >> > > I guess this is really the crucial part here. Are you able / willing / comfortable to potentially update the website or the tool if we approve the RFC about deprecation and are you sure that the current maintainer is ok with that (basically respect RFC as the governance method for PEAR)?
To make it simple, PEAR is part of the PHP projects. There was a separate group to do the admin work, security releases when needed, sync with php releases to bundle it, etc. For the purpose of fading out pear, and, more importantly, pecl, we can handle it here using the normal RFC flow. Most of the group members are barely (f.e. me) or not active at all anymore.
>> 1. mail the pear-dev ML and maintainers about the plan >> >> 2. disable any new releases, some are still released >> (f.e.https://pear.php.net/package/Log/) >> 3. add (future) service shutdown to the pear home page and/or in the >> site header >> 4. archive releases somewhere (static's php.net maybe?) >> 5. Once shutdown's date is reached, static page with link to the >> archive for the releases (for the few people still using them) >> > > Ok but this assumes that we are able to do 2 and 3.
And 1. :)
>> The removal for php's dists is obviously a good first step but I would >> not do it in minor releases tho'. I have seen internal projects here >> and there still running (php8 too :), and using pear, let's give them >> a last bit of time to see the light maybe? > > > If we are talking just about removing everything in php-src, then I don't think it's issue to get rid of it in 8.6 but we should for sure have RFC to decide it.
I agree, easy to greap the phar when needed but communication is key to avoid bad surprises. Maybe a pre warning in the upcoming 8.5 release. Best,
-- Pierre @pierrejoye | http://www.libgd.org

Jakub Zelenka

324 days ago
On Sun, Oct 12, 2025 at 5:30 AM Pierre Joye <pierre.php@gmail.com> wrote:
> On Sun, Oct 12, 2025 at 2:13 AM Jakub Zelenka <bukka@php.net> wrote: > > > Ok so I guess the current status is kind on unknown... :) But as noted > by Rowan in other email, there's a mention of the PEAR Group that is the > governing body of the project although seems expired so I have really no > idea what the governance there is and if the RFC process should have any > power over that project. > > > >> > I don't think that any current core developer has access to their GH > organizattion. Or do you still have access / control to do any changes > there and make it deprecated? My main issue with this RFC is that it's > about project that we don't effectively control and I'm not sure here is > anyone who can make any such change to it. From what I see it's currently > maintained by Chuck who, I guess, also control the project. Or am I wrong? > >> > >> I do have access, I did not check the role tho'. > >> > > > > I guess this is really the crucial part here. Are you able / willing / > comfortable to potentially update the website or the tool if we approve the > RFC about deprecation and are you sure that the current maintainer is ok > with that (basically respect RFC as the governance method for PEAR)? > > To make it simple, PEAR is part of the PHP projects. There was a > separate group to do the admin work, security releases when needed, > sync with php releases to bundle it, etc. > > For the purpose of fading out pear, and, more importantly, pecl, we > can handle it here using the normal RFC flow. Most of the group > members are barely (f.e. me) or not active at all anymore. >
Ok, if you say so and can make such change, I think we should put this RFC back for discussion. Kind regards Jakub

Nick

318 days ago
> For the purpose of fading out pear, and, more importantly, pecl, we > can handle it here using the normal RFC flow. Most of the group > members are barely (f.e. me) or not active at all anymore.
Hey Pierre, I understand you have access to the site. Because of that I answer here. The proposals with the IDs 710, 711, 708, 83, 662, 700 contain (mostly) online casinos links. Some of the proposals have the same account as last edit in their change log. Perhaps it makes sense to consider to disable editing old and adding new proposals. The last real proposal was in 2013. The newest three proposals sole purpose seems to be to get links in; for instance 710 is an exact copy of 83 from 21 years ago. Cheers Nick

Rowan Tommins [IMSoP]

325 days ago
On 10/10/2025 09:25, James Titcumb wrote:
> The short version of that discussion is that PEAR is maintained by > someone else; the PEAR group apparently is separate from the PHP > group, as I understand it.
The PEAR website has a list of members of the PEAR Group, but says that they were elected for a one-year term in 2009: https://pear.php.net/group/ I'm not sure whether elections were abandoned after that, or if the page was just not updated. The "News" page ends in 2007, but links to a now-defunct WordPress blog, which seems to have been maintained until 2018, after which I can't find any official announcements at all: https://web.archive.org/web/20181102164127/https://blog.pear.php.net/ The "pear-dev" list has had 3 threads this year, only 1 of which actually got a helpful response: https://news-web.php.net/group.php?group=php.pear.dev The "pear-general" list has had only 1 message this year, which went unanswered: https://news-web.php.net/group.php?group=php.pear.general The RSS activity feeds are mostly broken, but comparing archived package lists, I think the most recently approved package was Date_Holidays_Peru in 2019; and before that, File_Therion in 2016. I also had a look through the list of around 80 third-party channels here: https://pear.php.net/channels/ Other than pear.php.net and pecl.php.net, I could find only 8 that looked like they might still be usable. - https://empir.sourceforge.net/pear/ - https://pear.horde.org/ - https://pear.michelf.com/ - https://openpear.org/ - https://phpseclib.sourceforge.net/pear.htm - https://pear.phpundercontrol.org/ - http://pear.timj.co.uk/ - https://github.com/Smarre/antlrphpruntime The remainder are either non-existent/squatted domains, or projects whose installation instructions refer only to Composer, or occasionally PHAR downloads. There are still references to "PEAR2" and "Pyrus" here and there, but https://pear2.php.net doesn't even resolve Everything points to the entire project being essentially unmaintained: there are people here and there keeping the lights on, but little else. Since it was for a long time promoted as the official package manager for PHP, I think the PHP project has some responsibility - imagine, for instance, if there was a security breach of pear.php.net. I think as well as removing references in the manual and php-src, we should at minimum work to add disclaimers to the site that it is no longer officially endorsed by PHP, and perhaps pointing to a migration guide to Composer.
-- Rowan Tommins [IMSoP]

Nick

75 days ago
Hey all, I already mentioned this a few month ago in the "Deprecate PEAR and recommend Composer" RFC discussion. The discussion died down, no one picked up on it, and the RFC seems stale for now. Hence, re-sending it this as a new topic for visibility: On the PEAR website, the proposals with the IDs 710, 711, 708, 83, 662, 700 contain online casino links (and/or other spam). Some of the proposals have the same account as last editor in their changelog -- perhaps the account was hacked. The last real proposal was in 2013. The newest three proposals sole purpose seems to get links in. For instance, 710 is an exact copy of 83 from 21 years ago. Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam.
-- *Cheers* Nick

Derick Rethans

75 days ago
On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote:
>Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam.
You'll have to talk to the pear team for that, as we don't have access. cheers Derick

Davey Shafik

75 days ago
> On Jun 18, 2026, at 01:08, Derick Rethans <derick@php.net> wrote: > > On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote: > >> Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. > You'll have to talk to the pear team for that, as we don't have access. > > cheers > Derick
As a quick and dirty fix can we just deny any requests to the relevant endpoints and spam proposals at the CDN? - Davey

Derick Rethans

75 days ago
On 18 June 2026 09:26:01 BST, Davey Shafik <me@daveyshafik.com> wrote:
> >> On Jun 18, 2026, at 01:08, Derick Rethans <derick@php.net> wrote: >> >> On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote: >> >>> Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. >> You'll have to talk to the pear team for that, as we don't have access. > >As a quick and dirty fix can we just deny any requests to the relevant endpoints and spam proposals at the CDN?
It doesn't sit behind a CDN. And I have no access to the server. I can drop the whole hostname from DNS. cheers Derick

Nick

75 days ago
On 18.06.26 17:38, Derick Rethans wrote:
> On 18 June 2026 09:26:01 BST, Davey Shafik <me@daveyshafik.com> wrote: >>> On Jun 18, 2026, at 01:08, Derick Rethans <derick@php.net> wrote: >>> >>> On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote: >>> >>>> Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. >>> You'll have to talk to the pear team for that, as we don't have access. >> As a quick and dirty fix can we just deny any requests to the relevant endpoints and spam proposals at the CDN? > It doesn't sit behind a CDN. And I have no access to the server. > > I can drop the whole hostname from DNS. > > cheers > Derick
I sent Ken, who is listed on the PEAR website and just lately voted on a RFC, an email to ask if he has access. My previous attempt was answering to Pierre (who has access), which was unfortunately unanswered. Let's see if Ken is able to help here.
> I can drop the whole hostname from DNS.
Given that no one from PEAR group participated in the RFC discussion, and if Ken cannot help, this perhaps is an option. I think is a very bad look to have the spammed, unmaintained PEAR website on an official subdomain If I am reading your RFC comments correctly you are for removing the PEAR website from php.net altogether anyway? What was your conclusion to whether or not the RFC is required? Cheers Nick

Derick Rethans

75 days ago
On 18 June 2026 12:17:32 BST, Nick Sdot <php@nicksdot.dev> wrote:
>I sent Ken, who is listed on the PEAR website and just lately voted on a RFC, an email to ask if he has access. >My previous attempt was answering to Pierre (who has access), which was unfortunately unanswered. >Let's see if Ken is able to help here. > >> I can drop the whole hostname from DNS. > >Given that no one from PEAR group participated in the RFC discussion, and if Ken cannot help, this perhaps is an option. >I think is a very bad look to have the spammed, unmaintained PEAR website on an official subdomain > >If I am reading your RFC comments correctly you are for removing the PEAR website from php.net altogether anyway?
Yes
>What was your conclusion to whether or not the RFC is required?
I don't know. Probably as a curtesy. cheers Derick

Rowan Tommins [IMSoP]

75 days ago
On 18 June 2026 09:05:58 BST, Derick Rethans <derick@php.net> wrote:
>On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote: > >>Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. >> >You'll have to talk to the pear team for that, as we don't have access.
My email in October, copied to four different mailing lists plus the pear-group@ list alias, received exactly zero responses. Nobody else on this thread has reported any success either. I think it's safe to conclude that there is no PEAR team, the entire project is abandoned, and we need to decide what to do with the pear.php.net domain to protect the reputation of PHP. Probably that means setting up a read-only mirror somewhere and pointing the DNS at it so that clients don't break overnight. Rowan Tommins [IMSoP]

Derick Rethans

75 days ago
On 18 June 2026 12:34:17 BST, "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk> wrote:
>On 18 June 2026 09:05:58 BST, Derick Rethans <derick@php.net> wrote: >>On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote: >> >>>Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. >>> >>You'll have to talk to the pear team for that, as we don't have access. > >My email in October, copied to four different mailing lists plus the pear-group@ list alias, received exactly zero responses. Nobody else on this thread has reported any success either. > >I think it's safe to conclude that there is no PEAR team, the entire project is abandoned, and we need to decide what to do with the pear.php.net domain to protect the reputation of PHP.
I have had some conversations with <https://people.php.net/ashnazg> in the recent past.
>Probably that means setting up a read-only mirror somewhere and pointing the DNS at it so that clients don't break overnight.
I think that's good, but I still can't do that. Unless we scrape the existing site. (doable, but naughty). cheers Derick

Rowan Tommins [IMSoP]

75 days ago
On 18 June 2026 12:50:04 BST, Derick Rethans <derick@php.net> wrote:
>I think that's good, but I still can't do that. Unless we scrape the existing site. (doable, but naughty).
Yes, obviously better to do something based on the underlying data, but based on engagement up to now, I'm not optimistic about anyone providing that. Large parts of the site are broken already, and some parts like proposals wouldn't be worth preserving in a read-only version. So if we can't get access the priorities would presumably be: - scraping the package list, including download links - reconstructing the install channel, if we want the CLI client to keep working; this is probably the fiddliest part - scraping the Documentation section - maybe cloning the bug database, although like the rest of the project it's barely been touched in at least 5 years, so not sure how useful it is to anyone The alternative, as far as I can see, is just to take the whole thing offline. Leaving it up indefinitely in the vague hope that someone will step out of the shadows would mean accumulating spam and who knows what else on a php.net domain. Rowan Tommins [IMSoP]

Nick

75 days ago
On 18.06.26 20:38, Rowan Tommins [IMSoP] wrote:
> On 18 June 2026 12:50:04 BST, Derick Rethans <derick@php.net> wrote: > >> I think that's good, but I still can't do that. Unless we scrape the existing site. (doable, but naughty). > Yes, obviously better to do something based on the underlying data, but based on engagement up to now, I'm not optimistic about anyone providing that. > > Large parts of the site are broken already, and some parts like proposals wouldn't be worth preserving in a read-only version. > > So if we can't get access the priorities would presumably be: > > - scraping the package list, including download links > - reconstructing the install channel, if we want the CLI client to keep working; this is probably the fiddliest part > - scraping the Documentation section > - maybe cloning the bug database, although like the rest of the project it's barely been touched in at least 5 years, so not sure how useful it is to anyone > > The alternative, as far as I can see, is just to take the whole thing offline. Leaving it up indefinitely in the vague hope that someone will step out of the shadows would mean accumulating spam and who knows what else on a php.net domain. > > > Rowan Tommins > [IMSoP]
To my surprise the PEAR organisation on GitHub has activity. I found the email addresses of Daniel and Chuck (both also listed on the PEAR website), who recently merged PRs, and I mailed them. Let's see if we can get an answer. Cheers Nick

Unnamed Person

75 days ago
On 18-6-2026 13:34, Rowan Tommins [IMSoP] wrote:
> On 18 June 2026 09:05:58 BST, Derick Rethans <derick@php.net> wrote: >> On 18 June 2026 07:13:13 BST, Nick Sdot <php@nicksdot.dev> wrote: >> >>> Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. >> > I think it's safe to conclude that there is no PEAR team, the entire project is abandoned, and we need to decide what to do with the pear.php.net domain to protect the reputation of PHP. > > Probably that means setting up a read-only mirror somewhere and pointing the DNS at it so that clients don't break overnight.
Just a heads-up: I would very much favour some form of a readonly version of the site to stay available - probably with a banner that this is only still available for archive purposes (and disable any logins and form-submissions except admin). I, for one, still semi-regularly have to go back to the issue tracker on the PEAR site to dig up the reasoning/motivation for decisions taken long ago for an old codebase, where the commit messages, especially for older commits, are not great. Not being able to do so anymore would definitely have some impact on the work being done on that codebase. Smile, Juliette

Unnamed Person

41 days ago
On 18-6-2026 18:33, Juliette Reinders Folmer wrote:
> On 18-6-2026 13:34, Rowan Tommins [IMSoP] wrote: >> On 18 June 2026 09:05:58 BST, Derick Rethans<derick@php.net> wrote: >>> On 18 June 2026 07:13:13 BST, Nick Sdot<php@nicksdot.dev> wrote: >>> >>>> Perhaps it would make sense to disable editing old and adding new proposals, and remove the spam. >>> >> I think it's safe to conclude that there is no PEAR team, the entire project is abandoned, and we need to decide what to do with the pear.php.net domain to protect the reputation of PHP. >> >> Probably that means setting up a read-only mirror somewhere and pointing the DNS at it so that clients don't break overnight. > > Just a heads-up: I would very much favour some form of a readonly > version of the site to stay available - probably with a banner that > this is only still available for archive purposes (and disable any > logins and form-submissions except admin). > > I, for one, still semi-regularly have to go back to the issue tracker > on the PEAR site to dig up the reasoning/motivation for decisions > taken long ago for an old codebase, where the commit messages, > especially for older commits, are not great. > > Not being able to do so anymore would definitely have some impact on > the work being done on that codebase. >
Was just trying to dig up the background of some old bugfixes on the PEAR website and when I click to see the details of an individual bug report, I now get an "ERROR: the user who submitted this bug has not yet confirmed their email address" page instead of seeing the bug details. Example: https://pear.php.net/bugs/bug.php?id=20093 Clearly this is not helpful. Not sure when this changed, but felt like something related to last month's conversation, so I figured I'd flag it.

Nick

75 days ago
On 09.10.25 17:28, James Titcumb wrote:
> Folks, > > Presenting the RFC for deprecating PEAR and recommending Composer as > the recommended > PHP package installer: > > https://wiki.php.net/rfc/deprecate_pear_recommend_composer > > Plan to move to vote on or shortly after 24th October all being well. > > Thanks > James
Hey James, are you still planning and have time to bring this RFC to vote? The PEAR website in it's current state is really a bad look for PHP and your RFC would solve this. If I can help you in any way I'd be happy to. @all Has anyone anything that should be mentioned in the RFC text that is not mentioned yet? Or does anyone have anything that should/must be changed? So far the discussion reads as everyone is in favour. The only issue seems to be that no one knows how to actually approach it without any PoC at PEAR? Pier proposes something, but since no once is reachable it cannot be done like that. If no one has anything to add, and there would be no objections, would we still need to wait 14 days (++) until this can be voted on? Would be great if we could get this RFC picked up, and hopefully voted on soon! Cheers Nick

James Titcumb

71 days ago
On Thu, 18 Jun 2026, at 13:08, Nick Sdot wrote:
> Hey James, > > are you still planning and have time to bring this RFC to vote?
After some discussion and new-to-me discoveries, I don't think there is much we can actually do, hence why I abandoned the RFC. In practice, the only association "the PEAR group" has to "the PHP group" is that the `pear.php.net` website points to some infrastructure hosted by "the PEAR group". It seems that "deprecating PEAR" is not really within the remit of the wider PHP community hence an RFC would not be appropriate; it's like making an RFC to deprecate Packagist... it's just not something that can be done, nor is it relevant to "the PHP group"/internals. AFAIK, the only "switch" we have available is to remove the `pear.php.net` DNS record, but that could potentially disrupt people still relying on `pear.php.net`, so is something I would NOT be in favour of. Practically, we need someone from the PEAR group to engage in discussion about the next steps, but as far as I'm aware, no-one is responding. Thanks James