Bug 72033
Summary: | Completely broken default php.ini file | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Bernd Bartmann <bernd.bartmann> |
Component: | php | Assignee: | Phil Copeland <copeland> |
Status: | CLOSED NOTABUG | QA Contact: | David Lawrence <dkl> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.3 | CC: | ml-bz-dale |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2002-08-24 22:13:49 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bernd Bartmann
2002-08-20 20:18:40 UTC
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 =--= |