From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513 Description of problem: Yes, I've read in the errata release note that the admin should take care of the correct settings in the php.ini file. I can understand this argument but I think you should really provide a config file which at least has some proper defaults. The biggest problem I've found are the extension= lines. They're all made for PHP on windows, e.g. ;extension=php_mysql.dll. On linux we don't have *.dll files here they are called *.so. So for MySQL to work this should read extension=mysql.so. I'm an expirienced Red Hat user since years and know how to change this. But Joe user will never get PHP with MySql working with these strange default settings. Every time the same problems when a new PHP errata appears. This drives me crazy. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. Apply the new PHP errata php-4.1.2-7.3.3.i386.rpm 2. Look in /etc/php.ini.rpmnew for the sample extension= lines Additional info:
You also should add a section to the errata release notes stating that it is necessary to restart apache after the update with something like: service httpd restart
Another problem: Why is the mtime of the old php.ini changed to the update install time. An ls gives: [root@swextitt etc]# ls -l php* -rw-r--r-- 1 root root 23718 Aug 20 22:58 php.ini -rw-r--r-- 1 root root 27561 Aug 2 22:50 php.ini.rpmnew One could think that php.ini has been updated although this is not the case.
1) the commented out .dll lines are replaced by correct .so lines by the corresponding php-{mysql,pgsql,whatever} package install scripts. see rpm -qp --scripts package. it does a perl -pi. 2) the mtime of your php.ini is because of the perl -pi the install/uninstall scripts do, as I just explained. there's no way around this. 3) not restarting any services follows normal redhat update policy. your apache isn't automatically restarted on apache update. A REAL problem with the update php packages are that there are dependencies on e.g. postgresql and imap packages in the main php package even though there isn't a single executable or library in the package that would require those packages. These dependencies should only appear on the corresponding subpackages. - heko
Thanks, this gives more light to me, but: 1) Shouldn't this instead happen to php.ini.rpmnew cause here you'll find all the new options provided by the errata?! 2) See 1) if you change php.ini.rpmnew this problem would not occur. 3) You are right here. I have no problem restarting the services manually. But I think you should mention that it is necessary to restart the services in the errata announcement/release notes to take the changes into effect. Otherwise Joe user will apply the errata but is still running the old code which is still loaded in memory.
In my opinion, the errata (at least) is definitely broken. Presumably because of the script editing of /etc/php.ini on the previous installation I think it will always make /etc/php.ini.rpmnew, and then I think installation of the ancillary php packages (php-pgsql, et. al.) will always edit /etc/php.ini, thereby leaving php.ini.rpmnew unedited (and therefore broken). One possible solution would be for the ancilliary php package scripts to be modified to edit php.ini.rpmnew if it's present, otherwise php.ini. Also, referring to the earlier comment, I thought it *was* general Red Hat practice to restart daemons modified by an update (at least, by an up2date). In this case, that would be apache/httpd. Given that some people assume their system is being *automatically* kept up to date via up2date, failing to restart dependent daemons leaves systems running without the update until the next reboot. That's a bad thing.
Red Hat rpm policies 101 We do NOT overwrite existing config files, ever. (or rather if we find people doing it we take them outside and shoot them) We do NOT restart services from rpm spec files (or rather if we find people doing it we take them outside and feed them to the catapillers) The php errata is within spec although the first errata slipped through QA with a pile of requires: where they should have been buildrequires: see #72007 for additional details btw: I can see where you're going with the 'well if you arn't going to do php.ini, at least do php.ini.new. I've queued that up for another errata Phil =--=