RPM package naming for alternative configurations

Question

I currently install PHP from source in several different configurations around my environment, each providing the minimum feature set required for its particular deployment: one deployment requires UNIX socket support via '--enable-sockets', for example, but I choose not to provide that feature in other deployments for security's sake.

I'd like to build this into an RPM, but I'm unsure how to handle these config variations: should I build a separate 'php-sockets' package that provides a PHP built with '--enable-sockets'? Is there a way to provide a single named package that can be deployed with different build options? Can I roll all this up into a single spec file so that new updates to PHP can be made to automatically build all the different variants I require?

I'm out of my RPM depth on this one - educate me, please!

Answer 1

Either way you will need to have two separate packages. However there is another way you could solve this. You could divide your php packages into three distinct package groups, core, sockets, no-sockets. In this case core would contain all files which are common between the sockets and no-sockets compile options. Then the sockets and no-sockets versions would be compiled with the appropriate options, but will require the core package. This method is used in the Zabbix packages in Fedora. You can have a look at the spec file there if you are interested.

Answer 2

Since PHP sockets can be built into a separate extension, I recommend you look at how existing SRPMs build and package their extensions and follow the same thing with your own php-sockets extension package. Note that vendor packages usually provide sockets built-in, and so you may run into some distant packages that expect it to be installed as part of the php package.