Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128974
Precedence: list
MIME-Version: 1.0
References: <CAOD_yv0k=1nBq6LOR9w2pNXHnjtPL5NtBV=SLRsKjpVCK1dFug@mail.gmail.com>
 <fdf1d284-27bf-4bb2-924e-21fa82673c6f@gmx.de> <CAOD_yv2Sga6P1N-Uu2w-nyyY-XMvytWy-_r1v=xZpygQ_67iRQ@mail.gmail.com>
 <CAEZPtU6NJfxjckrpikVfmFcJ2OyhhKg3YJdqTkpvPaU_uMeyGg@mail.gmail.com>
 <CAEKnhAEsGS+k7Mg4Z1z-fbWh4hsAbkpgTxsdJEYaG7N1+F=Ddg@mail.gmail.com>
 <CANSNCr1paQGq3Vg0MKsNkZagtRweGpQuu9jy-bpnot_=RbLv-g@mail.gmail.com>
 <CAEKnhAGEzupa25BbWy60h_EKrM9e0txm2Tao+vZON=Ob=ce-Bw@mail.gmail.com>
 <c1451dfa-c38a-f421-66c9-aa51b949aeb9@php.net> <CAEZPtU4gg7whzhNjF+fGzV6FyA03HSCDBPVoLFm9qT5ijZ5SUw@mail.gmail.com>
 <768bc888-7ae3-4143-8100-97b626da6350@rwec.co.uk> <a22a72cb-d946-429c-89d0-ca4f71c43a80@rwec.co.uk>
In-Reply-To: <a22a72cb-d946-429c-89d0-ca4f71c43a80@rwec.co.uk>
Date: Mon, 27 Oct 2025 10:08:58 +0100
Message-ID: <CAEKnhAHLcJnfffhZS9dAowZ07G4apotrEEHqSZ8xtfWFRiZXyA@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate PEAR and recommend Composer
To: "Rowan Tommins [IMSoP]" <imsop.php@rwec.co.uk>
Cc: internals@lists.php.net
Content-Type: multipart/alternative; boundary="0000000000008a80eb0642204085"
From: bukka@php.net (Jakub Zelenka)

--0000000000008a80eb0642204085
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

On Sun, Oct 26, 2025 at 2:38=E2=80=AFPM Rowan Tommins [IMSoP] <imsop.php@rw=
ec.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.

2. 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.


> 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.


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

--0000000000008a80eb0642204085
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Hi,</div><div dir=3D"ltr"><div dir=3D"ltr"><br></div>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Oc=
t 26, 2025 at 2:38=E2=80=AFPM Rowan Tommins [IMSoP] &lt;<a href=3D"mailto:i=
msop.php@rwec.co.uk" target=3D"_blank">imsop.php@rwec.co.uk</a>&gt; wrote:<=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex">
As such, I propose:<br>
<br>
1. We remove all references to PEAR in php-src, such as build options <br>
and installation instructions.<br>
<br></blockquote><div><br></div><div>I have already started this in=C2=A0<a=
 href=3D"https://github.com/php/php-src/pull/20124">https://github.com/php/=
php-src/pull/20124</a> but it&#39;s that simple as it got a bit rooted to t=
he php-src. It will take some time though. I might just merge it if there a=
re no objection so it might not even need RFC unless there are any objectio=
n.</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
2. We remove any references in the PHP manual, and add a suggestion to <br>
look at Composer, as an unofficial but popular package manager.<br>
<br></blockquote><div><br></div><div>That&#39;s a good and I don&#39;t thin=
k we even need RFC for this either.</div><div>=C2=A0</div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex">
3. We immediatlely make the Package Proposals system (&quot;PEPr&quot;) rea=
d-only.<br>
<br>
4. We add a banner in the header on <a href=3D"http://pear.php.net" rel=3D"=
noreferrer" target=3D"_blank">pear.php.net</a> announcing that the <br>
site and channel will shut down at the end of 2026. This can link to a <br>
page which includes tips on installing the same packages using Composer.<br=
>
<br>
<br>
Steps 3 and 4 obviously require someone to have access to deploy a new <br>
version of the website. It&#39;s not clear exactly who has that access, but=
 <br>
I imagine we can find someone if there is consensus on the changes.</blockq=
uote><div><br></div><div>Well I guess Chuck is the only person who can do t=
hat so without any response from him, there is not much we can do. I&#39;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.</div><div><br></=
div><div>Kind regards</div><div><br></div><div>Jakub</div></div></div>
</div>

--0000000000008a80eb0642204085--