The files mentioned are those in /usr/lib/systemd/system/httpd.service.d/ - the forum was telling me I was posting too many links so I deleted several things from the original post to try to get something it'd accept (the post didn't actually gave any links).

Thank you for replying. I don't want them all to run at the same time, and I do want to have ones installed that aren't running. My use case is that people are generally using the appliances to clone, tweak and test their websites.
For example, perhaps their live website is running on an older PHP version. They clone it to my appliance, and then they press a button to change the PHP version. Under the hood, this stops one version of PHP-FPM and starts another. So, the PHP-FPM instances don't run at the same time. They use the same TCP socket, so that it's not necessary to change the Apache configuration, or configure multiple ports in SELinux.
Or to give another example, perhaps they are a WordPress plugin/theme developer. They have a test site that they run on the appliance, and they click the button to change PHP versions to test/develop on those different versions. Again, there's only ever one PHP-FPM version running at a time, and to accomplish this, all the script behind the "change PHP version" button is having to do is "systemctl stop php81-php-fpm; systenmctl start php82-php-fpm" (no need to reconfigure Apache or enable multiple TCP ports in SELinux, etc.).

In fact, the appliance supports PHP 5.4 up to 8.2 (as I say, one use case is people cloning their website running on a very old version, in order to test the experience of upgrading to a new one, without having to test on the live site). That's 11 PHP versions in total. To be running all 11 at the same time would mean the appliances would need substantially more RAM.

From your reply above, it sounds like this isn't compatible with the set of packages on RHEL 8 as it was on RHEL 7? i.e. I may have to create a custom solution to delete those systemd unit files each time packages are updated or they otherwise reappear?

Could you not accomplish your current goals by pre-setting php*-php-fpm to be enabled in systemd, but not having the "Wants=" ? This would mean that upon first install, it would be enabled, but it would also mean that people like me who want to disable it can do so without having the "Wants=" making that disabling to have no effect (as it gets started anyway when Apache starts).

Thank you. Sorry to be slow, but what should be made to conflict with what? If I make each php-fpm to conflict with every other php-fpm, then on reboot won't that still result in the highest version number being the one that's loaded (through "Wants"), rather than the one I wanted?

i.e. The same result as currently, when all except one of them abort because they couldn't get the TCP socket anyway (since the first one already got it). That is to say, they already conflict in practice, so I only get one: it's just not the one I wanted.

I'll have to try to hack something up, then.

I still think that "Wants=" is wrong, as that implies that whenever httpd is running, then the administrator also wants php-fpm to be running, as if php-fpm were a dependency of httpd. i.e. It means that "if you installed it, you want it to be running". Even that could be done by having default activation and allowing the administrator to turn it off. But apparently there is no way to turn "Wants=" off, other than to wipe the file and then monitor it for future changes: the "you want it running" is effectively a permanent setting.

For what it's worth for anyone who's interested.... testing shows that adding "Conflicts=" to all of them (each php-fpm conflicts with each other php-fpm) does mean (as the systemd documentation suggests) that only one will run at once, and that starting a second one will stop the first one.

However, which one actually gets started is basically random (depends on some race) - running "systemctl restart httpd" gives me a different one each time.

So, though it may well be a design choice, it is also one that makes legitimate, real-world use cases impossible to implement without hacks. So if it is reviewed again in another 5 years' time, it would be nice to support this use case. I expect the most reliable work-around will be for me to use "systemctl mask" on all the ones I don't want to run. i.e. It's necessary to go to the "nuclear" version of what "disable" ought to be doing.

After discussion with httpd maintainer

Fixed in Fedora 39

For httpd:
https://src.fedoraproject.org/rpms/http … ch=rawhide
https://src.fedoraproject.org/rpms/http … ch=rawhide

For php:
https://src.fedoraproject.org/rpms/php/ … ch=rawhide

For my repository, applied for PHP 8.3
Will consider stable versions later (and for a RC build)