Re: [RFC] [Discussion] Deprecate PEAR and recommend Composer

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. > 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.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, -- Pierre @pierrejoye | http://www.libgd.org