To modify system service configuration (
systemd (1) service units), the user should not touch or modify unit files under the
/usr/ file structure directly, as changes in those files will be lost after a system software update with
The user should create configuration files as needed and avoid modifying distribution provided defaults.
“php’s default configuration file doesn’t allow us to provide an alternative as it is programmed to only read the builtin file.”
A user shouldn’t modify anything under /usr but php-fpm is programmed only to ready the built in file under
What about php.ini located /usr/share/defaults/php/php.ini assume same for php-fpm.conf ?
What else is valid, since php-fpm does’t allow Clear Linux to provide an alternative path, is php-fpm excluded and immune from being overwritten by swupd or will swupd treat php.ini and php-fpm.conf like everything else and overwrite php.ini?
Since we have to use the php.ini file to add extensions from php-extras bundle, can we safely modify php.ini in it’s default location
/usr/share/defaults/php/php.ini. and not have to worry about swupd trashing the file?
Reading what user must do to use a different config contradicts the stateless paradigm because it requires the user TO MODIFY
/usr/share/defaults/php/php-fpm.conf before copying it over to /etc
It makes little practical sense having swupd destroy default located php.ini, because every time php is updated and wipes out the php.ini file we’d have to continually run through the process of modifying the conf file and copying it over to /etc.
So who has an explanation to clarify the situation with php-fpm and the consequences of swupd?