The php eclass directly overwrites any existing /etc/php/<sapi>-php4/php.ini file on the system. Any existing settings set by the user are lost. This includes any settings added by php extensions such as turck-mmcache. The attached patch fixes this problem. As an aside, I'm not sure whether re-creating /etc/php4 is a good idea ;-) Would you mind changing it so that /etc/php4 is not created if it doesn't exist? Best regards, Stu
Created attachment 14907 [details, diff] Diff for php.eclass to fix this bug.
No, Stu this seems to be a bug with newins, please report it to carpaski. NO install function should overwrite things in CONFIG_PROTECT under any circumstancces.
Robin - thanks for looking at this. I've had a quick chat with carpaski on IRC, and have re-assigned this bug to him.
Bah! Okay, after a chat on IRC with Azarah, and a *lot* more testing ... The php.ini file is actually getting overwritten by the code which tries to make /etc/php4/php.ini a symlink. That's one for robbat2 ;-) Using newins to install php.ini-5 as /etc/php/apache2-php4/php.ini isn't working at all. Using doins doesn't work reliably. I don't know why this is the case - I cannot explain it. I can verify that the ini file definitely is present under the image/ directory, but it isn't installed into the live filesystem. The timestamp on the ini file in the live filesystem is changed, but not the contents of the file itself. Go figure. Atm, anyone who upgrades to mod_php-4.3.2-r4 will end up losing their php.ini files. Once -r4 is marked stable, and the GLSA released, it seems that we'll have quite a few unhappy users ;-( Best regards, Stu
Just a note to say that I've upgraded my local portage to the latest unstable version available, and this is now working fine. Stu
