[RFC] [Discussion] Deprecate PEAR and recommend Composer

9 months ago by James Titcumb — view source — reply

unread

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

9 months ago by Christoph M. Becker — view source — reply

unread

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

9 months ago by James Titcumb — view source — reply

unread

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.

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

9 months ago by Pierre Joye — view source — reply

unread

Hi James,

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.

9 months ago by Jakub Zelenka — view source — reply

unread

Hi,

Hi James,

On Fri, Oct 10, 2025, 3:29 PM James Titcumb titcumbjames@gmail.com
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

9 months ago by Brent Roose — view source — reply

unread

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

Hi,

Hi James,

On Fri, Oct 10, 2025, 3:29 PM James Titcumb titcumbjames@gmail.com
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

9 months ago by Jakub Zelenka — view source — reply

unread

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

9 months ago by Jakub Zelenka — view source — reply

unread

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

8 months ago by Derick Rethans — view source — reply

unread

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

8 months ago by Pierre Joye — view source — reply

unread

Hi Derick,

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

8 months ago by Rowan Tommins [IMSoP] — view source — reply

unread

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]

8 months ago by Sebastian Bergmann — view source — reply

unread

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

8 months ago by Pierre Joye — view source — reply

unread

Hi,

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

8 months ago by Rowan Tommins [IMSoP] — view source — reply

unread

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]

8 months ago by Rowan Tommins [IMSoP] — view source — reply

unread

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.

It has now been a week since I sent out my messages. Pierre has also
CC'd Chuck Burgess (twice, first more than two weeks ago) and Christian
Weiske.

There have been no responses.

While it's possible that some interested parties haven't had a chance to
see and respond, all signs point to the same thing: there is no
currently active PEAR Group, and no active PEAR community to elect a new
one.

There is also nobody actively maintaining the website, and nobody likely
to do so if it moved to a new domain.

The pear.php.net website was set up by, and remains the copyright of,
the PHP Group, so arguably they have the final say on its fate.

For now, I think this list is as good a place as any to openly discuss
proposals.

As such, I propose:

We remove all references to PEAR in php-src, such as build options
and installation instructions.
We remove any references in the PHP manual, and add a suggestion to
look at Composer, as an unofficial but popular package manager.
We immediatlely make the Package Proposals system ("PEPr") read-only.
We add a banner in the header on pear.php.net announcing that the
site and channel will shut down at the end of 2026. This can link to a
page which includes tips on installing the same packages using Composer.

Steps 3 and 4 obviously require someone to have access to deploy a new
version of the website. It's not clear exactly who has that access, but
I imagine we can find someone if there is consensus on the changes.

The details of the text can be prepared in public as a pull request to
https://github.com/pear/pearweb/

If, during the next year, someone steps forward to run a fork of the
site on a new domain, we can discuss how to transfer the data. If, as
seems more likely, nobody does so, we can discuss exactly what read-only
archive we are willing to maintain.

I would be willing to either take over Asgrim's RFC or write a new one
with this proposal, so that we can confirm consensus with a vote.

--
Rowan Tommins
[IMSoP]

8 months ago by Jakub Zelenka — view source — reply

unread

Hi,

On Sun, Oct 26, 2025 at 2:38 PM Rowan Tommins [IMSoP] imsop.php@rwec.co.uk
wrote:

As such, I propose:

We remove all references to PEAR in php-src, such as build options
and installation instructions.

I have already started this in https://github.com/php/php-src/pull/20124
but it's that simple as it got a bit rooted to the php-src. It will take
some time though. I might just merge it if there are no objection so it
might not even need RFC unless there are any objection.

We remove any references in the PHP manual, and add a suggestion to

look at Composer, as an unofficial but popular package manager.

That's a good and I don't think we even need RFC for this either.

We immediatlely make the Package Proposals system ("PEPr") read-only.

We add a banner in the header on pear.php.net announcing that the
site and channel will shut down at the end of 2026. This can link to a
page which includes tips on installing the same packages using Composer.

Steps 3 and 4 obviously require someone to have access to deploy a new
version of the website. It's not clear exactly who has that access, but
I imagine we can find someone if there is consensus on the changes.

Well I guess Chuck is the only person who can do that so without any
response from him, there is not much we can do. I'm not sure if it makes
much sense doing RFC about something that we cannot do. I mean it all
really depends if he is happy to do that. But maybe it can be just some
sort of a symbolic thing that sends a signal.

Kind regards

Jakub

9 months ago by Pierre Joye — view source — reply

unread

Hi,

Hi James,

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:

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)

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

9 months ago by Rowan Tommins [IMSoP] — view source — reply

unread

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]

9 months ago by Jakub Zelenka — view source — reply

unread

Hi,

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:

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/)
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

9 months ago by Pierre Joye — view source — reply

unread

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.

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.

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

8 months ago by Jakub Zelenka — view source — reply

unread

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

8 months ago by Nick — view source — reply

unread

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

9 months ago by Rowan Tommins [IMSoP] — view source — reply

unread

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.

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]

3 weeks ago by Nick Sdot — view source — reply

unread

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

3 weeks ago by Derick Rethans — view source — reply

unread

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

3 weeks ago by Davey Shafik — view source — reply

unread

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

3 weeks ago by Derick Rethans — view source — reply

unread

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

3 weeks ago by Nick Sdot — view source — reply

unread

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

3 weeks ago by Derick Rethans — view source — reply

unread

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

3 weeks ago by Rowan Tommins [IMSoP] — view source — reply

unread

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]

3 weeks ago by Derick Rethans — view source — reply

unread

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

3 weeks ago by Rowan Tommins [IMSoP] — view source — reply

unread

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]

3 weeks ago by Nick Sdot — view source — reply

unread

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

3 weeks ago by Juliette Reinders Folmer — view source — reply

unread

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

3 weeks ago by Nick Sdot — view source — reply

unread

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

2 weeks ago by James Titcumb — view source — reply

unread

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