Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:128813
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>
In-Reply-To: <CAEKnhAEsGS+k7Mg4Z1z-fbWh4hsAbkpgTxsdJEYaG7N1+F=Ddg@mail.gmail.com>
Date: Sat, 11 Oct 2025 16:32:26 +0700
Message-ID: <CAEZPtU4PLw7-Tu4vUVqHus71maeTsQuAKQxVbqLxSkY9eErDyg@mail.gmail.com>
Subject: Re: [PHP-DEV] [RFC] [Discussion] Deprecate PEAR and recommend Composer
To: Jakub Zelenka <bukka@php.net>
Cc: james@asgrim.com, "Christoph M. Becker" <cmbecker69@gmx.de>, 
	PHP Internals List <internals@lists.php.net>, ashnazg@php.net
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
From: pierre.php@gmail.com (Pierre Joye)

On Fri, Oct 10, 2025 at 5:36=E2=80=AFPM Jakub Zelenka <bukka@php.net> wrote=
:
>
> Hi,
>
> On Fri, Oct 10, 2025 at 12:01=E2=80=AFPM Pierre Joye <pierre.php@gmail.co=
m> wrote:
>>
>> Hi James,
>>
>> On Fri, Oct 10, 2025, 3:29 PM James Titcumb <titcumbjames@gmail.com> wro=
te:
>>>
>>> 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 Founda=
tion 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 some=
one else; the PEAR group apparently is separate from the PHP group, as I un=
derstand 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 orga=
nizattion. Or do you still have access / control to do any changes there an=
d make it deprecated? My main issue with this RFC is that it's about projec=
t 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 C=
huck 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 agreem=
ent with the current maintainers.

I don't see a point in moving the DNS entry away, that makes little
sense. A few steps toward shutdown permanently, once or if agreed to:

1. mail the pear-dev ML and maintainers about the plan
2. disable any new releases, some are still released
(f.e.https://pear.php.net/package/Log/)
3. add (future) service shutdown to the pear home page and/or in the
site header
4. archive releases somewhere (static's php.net maybe?)
5. Once shutdown's date is reached, static page with link to the
archive for the releases (for the few people still using them)


The removal for php's dists is obviously a good first step but I would
not do it in minor releases tho'. I have seen internal projects here
and there still running (php8 too :), and using pear, let's give them
a last bit of time to see the light maybe?

As of pecl, the same could be applied. I do not know for PIE, but if
needed, pickle has the code to migrate package(1|2).xml, target needs
to be changed then to what PIE uses now, that's something maintainers
of exts can do. Unmaintained ones can go to the archives as well.

best,
--=20
Pierre

@pierrejoye | http://www.libgd.org