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
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:PHP: 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
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:
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
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.
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
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:
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:
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:
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
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
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
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
PEAR - PHP Extension and Application Repository · GitHub. 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.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
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
PEAR - PHP Extension and Application Repository · GitHub. 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]
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: The PEAR 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: php.pear.dev mailing list The "pear-general" list has had only 1 message this year, which went unanswered: php.pear.general mailing list
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: Channels Other than pear.php.net and pecl.php.net, I could find only 8 that looked like they might still be usable.
- Just the Empir channel
- https://pear.horde.org/
- https://pear.michelf.com/
- https://openpear.org/
- PHP Secure Communications Library PEAR channel
- https://pear.phpundercontrol.org/
- http://pear.timj.co.uk/
- GitHub - Smarre/antlrphpruntime: antlr PHP runtime
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]
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:
- mail the pear-dev ML and maintainers about the plan
- disable any new releases, some are still released
(f.e.https://pear.php.net/package/Log/)- add (future) service shutdown to the pear home page and/or in the
site header- archive releases somewhere (static’s php.net maybe?)
- 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
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...
> 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.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
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…
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
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:
>
> - PHP: rfc:deprecate-pear-include-composer
> - PHP: rfc:global_login
> - PHP: 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:
>
> - PHP: rfc:unbundle_imap_pspell_oci8
> - PHP: rfc:unbundle_xmlprc
> - PHP: rfc:deprecate-and-remove-ext-wddx
> - PHP: 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: Xdebug: Support
mastodon: @derickr@phpc.social @xdebug@phpc.social
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
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]
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
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
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:
> >
> > - PHP: rfc:deprecate-pear-include-composer
> > - PHP: rfc:global_login
> > - PHP: 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:
> >
> > - PHP: rfc:unbundle_imap_pspell_oci8
> > - PHP: rfc:unbundle_xmlprc
> > - PHP: rfc:deprecate-and-remove-ext-wddx
> > - PHP: 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