[PHP-DEV] [RFC] [Discussion] Deprecate PEAR and recommend Composer

Mailing Lists php.internals
21

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]

22

On 20/10/2025 14:10, Rowan Tommins [IMSoP] wrote:

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:

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

2. We remove any references in the PHP manual, and add a suggestion to look at Composer, as an unofficial but popular package manager.

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

4. 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 GitHub - 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]

23

Hi Christian.

On Sun, Oct 26, 2025 at 6:09 PM Christian Weiske <cweiske@cweiske.de> wrote:

Hello,

>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 don't have access to box anymore; Chuck volunteered to keep the
server updated.

I'm all for archiving the site to static files.

I hope you are doing well!

If my memory serves me correctly, pear command has a download all or
similar. I think a static page informing visitors that the site has
been taken down and a link to the files archives if anyone still
relies on specific package(s)/versions. That's the most important part
I suppose, as we all had these projects where something was insanely
outdated and needed to get it running again somehow first ;-).

Best,
--
Pierre

@pierrejoye | http://www.libgd.org

24

Hi,

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

As such, I propose:

  1. 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.

  1. 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.

  1. We immediatlely make the Package Proposals system (“PEPr”) read-only.

  2. 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