Description of problem: The /etc/php.ini file for php-5.0.4-10.5.i386 Version-Release number of selected component (if applicable): 5.0.4-10.5 How reproducible: Every time Steps to Reproduce: 1. Upgrade to php-5.0.4-10.5 2. Test web app relying on, e.g., php-mysql and /usr/lib/php/modules/mysql.so Actual results: Breakage, debugging indicates dl() looks for /usr/lib64/php4; /etc/php.ini contains the answer. Expected results: Happiness as always. Additional info: I'm not a Web server or PHP expert, just a user. If this entry is ignorant, please hit reporter with cluestick.
Not as shipped otherwise this would work for nobody. Run "rpm -V php" to see whether /etc/php.ini is modified from the shipped copy. Do you have an /etc/php.ini.rpmnew? If so rename it over /etc/php.ini. I'd suggest a "yum erase php" then a re-install of everything removed.
You're right, of course 2 min. after I filed the bug I found the same problem. My abject apologies for a rather stupid bug filing. :-( But there was no sign of customization -- i.e. no /etc/php.ini.rpmnew as expected for %config(noreplace). I saw a bug filed about that, but never made the connection until I downloaded the package, did an rpm2cpio | cpio -i and looked at the contents. Sorry to have wasted your time, thanks for not hitting me too hard. ;-)