Currently our php-fpm service script supports slotting in the script itself. If the service script is named "php-fpm" -- which it is by default -- then it will start/stop/reload the eselected version of php-fpm. However, if the service script is named e.g. php-fpm-5.6, then it will only manage the 5.6 slot of php-fpm. To accommodate all of that, there's some slot handling code at the top of the script: PHP_SLOT="${SVCNAME#php-fpm-}" if [ "${PHP_SLOT}" = "php-fpm" ] ; then PHP_SLOT="$(eselect php show fpm)" fi That makes our service script non-portable, since other distributions don't do slotting, and won't have the "eselect" command available. A smarter way to do this is the same way postgresql does it: create one service script per slot, and let the user decide which one to use. That would let us eliminate the slot-handling code from our service script, making it portable enough to upstream into dev-lang/php. The @variable@ substitutions would be handled by the dev-lang/php build system, and then we would install the service script with e.g. newinitd sapi/fpm/openrc.init "php-fpm-${SLOT}" Having the php-fpm service script installed by the same package that installs php-fpm would also be less weird than the situation we have now, where eselect-php installs the init script for another package.
FWIW, our systemd service scripts do the same thing. And there is already an upstream php-fpm.service that we might be able to use if we installed one copy per slot.
if options in conf.d can be shared between versions, i'd recommend php-fpm.${SLOT} instead, the dot tells openrc to load both conf.d/php-fpm and then load conf.d/php-fpm.${SLOT}, this also avoids breakage on current configurations that probably use conf.d/php-fpm (though it would break for those using conf.d/php-fpm-${SLOT}, as that now needs to use a dot instead of a dash)
