Hi
On 2026-10-06 14:21, Matthieu Napoli wrote:
If there is a real need, I see two simpler options:
I'm not sure there is a *real need*, but it's a theoretical breaking
change with no way to work around from what I can tell. A hypothetical
use case could be “spawn customer-specific FPM pools from a PHP-based
control panel”, for example for some playground.
- `php-fpm` could ignore `--fpm` so that `PHP_BINARY --fpm ...` always
work
That suggestion makes sense to me and would resolve the above: `php-fpm`
would just mean `php --fpm` and `php --fpm --fpm` would then just be a
duplicate `--fpm` flag. Ordering matters with regard to `--fpm`, but
that seems obvious enough to explain.
The RFC also notes that the standalone PHP FPM binary will remain an
option. Is there any reason to keep support for that, except for
backward compatibility?
No. I'd find this preferable to drop `php-fpm` in a separate step/RFC
since that's a fairly big breaking change for packagers.
Should the “this” in “this preferable” mean “it” instead? The “this” in
your phrasing could refer to my suggestion, which doesn't make sense to
me.
In any case, packagers already need to deal with all kinds of packaging
changes (e.g. OPcache becoming non-optional in PHP 8.5). I'm not sure
adding one additional symlink and/or replacing `php-fpm` by `php --fpm`
in the service definition is any more complicated than that. Doing it
all in a single step would also mean that there is no weird intermediate
state where when providing support we would also need to differentiate
between “FPM” and “FPM as part of CLI”.
Best regard
Tim Düsterhus
