[RFC] Sunset PECL - Externals

3 days ago by Jakub Zelenka — view source — reply

unread

Folks,

I'd like to introduce an RFC to lay out a timeline to sunset PECL and open
it for discussion.

RFC text is at https://wiki.php.net/rfc/sunset_pecl

Nice. It might be good to add there that pie is also distributed in a
binary form so users on older PHP versions can use it too - that was one of
the main blockers before AFAIK.

Cheers

Jakub

3 days ago by James Titcumb — view source — reply

unread

Jakub,

Thanks for the feedback.

It might be good to add there that pie is also distributed in a binary form so users on older PHP versions can use it too - that was one of the main blockers before AFAIK.

That's a good point, and something that was initially (and technically still) experimental. I don't know what the usage stats are like, as we don't collect any metrics on PIE side, but it's definitely getting some usage. Perhaps we should start promoting that a little more, and remove the "experimental" flag, as it does indeed help that pre-PHP 8.1 issue.

I'll add a note to that effect, thank you!

Thanks
James

2 days ago by fennic log — view source — reply

unread

I don't know what the usage stats are like, as we don't collect any
metrics on PIE side, but it's definitely getting some usage. Perhaps we
should start promoting that a little more, and remove the "experimental"
flag, as it does indeed help that pre-PHP 8.1 issue.

PIE doesnt, but packagist does https://packagist.org/extensions

3 days ago by tim@bastelstu.be — view source — reply

unread

Hi

I'd like to introduce an RFC to lay out a timeline to sunset PECL and
open it for discussion.

RFC text is at https://wiki.php.net/rfc/sunset_pecl

Thank you. With Docker, arguably the main remaining user of manually
installing third party extensions, removing PECL from the images for PHP
8.6 and having a well-functioning PIE workflow this makes sense to me.
The proposed timeline also nicely coincides with the EOL of PHP 8.5, so
that there should not be any remaining Docker users that we would break.
It might make sense to add
https://github.com/docker-library/php/pull/1654 as a Reference to the
RFC and to spell out explicitly why this timeline works out nicely.

I have no other comments to the RFC.

Best regards
Tim Düsterhus

1 day ago by Rowan Tommins [IMSoP] — view source — reply

unread

I'd like to introduce an RFC to lay out a timeline to sunset PECL and
open it for discussion.

RFC text is at https://wiki.php.net/rfc/sunset_pecl

Hi James,

Thanks for moving this forward. I have a slight concern with the long
gap between going fully read-only (mid-2027) and retiring the repository
(end of 2029).

In one of the PEAR threads, I linked this blog post by Andrew Nesbitt
where he points out the risk of freezing a package which turns out to
contain a vulnerability:
https://nesbitt.io/2026/06/23/sunsetting-a-package-manager.html In the
current environment, two and a half years seems a long time to serve
something nobody can patch.

I think there are two ways we could lessen that risk:

Have a longer interim stage, where functionality is limited, and
deprecation clearly flagged, before going fully read-only.

For instance, registration of new packages could be disabled, and
perhaps restrictions placed on version numbers - e.g. allow Swoole
6.1.13 and 6.2.6 as patching existing series, but force 6.3.0 to be PIE
only.

We could also restrict packages from listing compatibility with new PHP
versions - there's probably no reason for anyone to use PECL to install
anything on PHP 8.7 / 9.0.

Establish a process up front for package maintainers to request
publication of security releases, with only a small number of users
granted write access.

As Andrew points out, if it's suitably restricted, this security process
doesn't need to use the same automation as the original system, it just
needs a way for trusted user to manually upload the releases.

What do you think?

--
Rowan Tommins
[IMSoP]

1 day ago by Derick Rethans — view source — reply

unread

I'd like to introduce an RFC to lay out a timeline to sunset PECL and open it for discussion.

Have a longer interim stage, where functionality is limited, and deprecation clearly flagged, before going fully read-only.

For instance, registration of new packages could be disabled,

It already is.

and perhaps restrictions placed on version numbers - e.g. allow Swoole 6.1.13 and 6.2.6 as patching existing series, but force 6.3.0 to be PIE only.

This will likely mean changing the peclweb code, and that's something we really shouldn't want to do. Nobody knows the code and it's decades behind the times.

We could also restrict packages from listing compatibility with new PHP versions - there's probably no reason for anyone to use PECL to install anything on PHP 8.7 / 9.0.

Same

Establish a process up front for package maintainers to request publication of security releases, with only a small number of users granted write access.

As Andrew points out, if it's suitably restricted, this security process doesn't need to use the same automation as the original system, it just needs a way for trusted user to manually upload the releases.

What do you think?

If the long static state is considered a problem, we can just shorten it be a year, and shutting it down a year sooner.

cheers
Derick

[RFC] Sunset PECL View as Markdown