Re: [RFC] Single binary for CLI and FPM

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