I just upgraded php. My previous config (in /etc/php/apache2-php5) was set to production values, but the new config (in /etc/php/apache2-php5.3) was installed with development values, so my clients saw a ton of debug / deprecation warnings. This should not have happened.
Ive had this happen to me in the past. Although it was my own fault for blindly accepting the updated config file (etc-update with the -3 option). However back in november i seen an artical on "planet" talking about how you can choose between the development and production versions of php.ini simply by adding an entry to make.conf. For now i have added PHP_INI_VERSION="production" to /etc/make.conf Here is a link to the referenced artical http://olemarkus.org/2010/10/choosing-between-development-and-production-version-of-php-ini/ There seems to be some disagreement as to which should be the default development or production.
No, this is not the case of blindly accepting an update in etc-update. As mentioned in the original text, the problem is that the new version installed a config to /etc/php/apache2-php5.3 whereas the previous config was in /etc/php/apache2-php5 (so there was nothing etc-update could do). The problem really is that the default should be to install the production ini file since that's most likely what is needed/wanted (and the development php file will break things like horde)
As for PHP_INI_VERSION="production" ... I will certainly add that, but it is unfortunate that this changed without much end-user notification: 1) The default has previously been production 2) The new (development) config is installed to a new location, so etc-update doesn't show changes 3) Most users want php to serve content, not develop scripts.
Furthermore, if you're going to make such a fundamental change like this, you should have it show up in 'emerge -uvD php -p' along with USE flags, INPUT_DEVICES, VIDEO_CARDS, etc ...
In addition to the above-mentioned blog post, you can also find details in the post install log of emerge: "This ebuild installed a version of php.ini based on php.ini-production version. You can chose which version of php.ini to install by default by setting PHP_INI_VERSION to either 'production' or 'development' in /etc/make.conf Both versions of php.ini can be found in /usr/share/doc/php-5.2.15" I find this to be enough documentation. One of the reason for moving from production to development version of php.ini is that those using php in production should REALLY pay attention to what goes on in their system. I still feel that this is the right decision.
You should not change defaults which will break production machines upon upgrade. You should not rely on everyone reading your blog before upgrading your packages. It is unreasonable for everyone to do that every day/week before they upgrade their system. Doing 'emerge -uvD @world @system --newuse' should *NOT* break a production machine, and if there is reason to do so, that should be explained in eselect-news. As for using a development version by default, you should not *CHANGE* the configuration on users without their consent. Furthermore, the now-default configuration causes numerous other packages (such as horde) to not work out of the box because of the strict conformance required by the development config.
(In reply to comment #6) > > You should not rely on everyone reading your blog before upgrading your > packages. It is unreasonable for everyone to do that every day/week before > they upgrade their system. Doing 'emerge -uvD @world @system --newuse' should > *NOT* break a production machine, and if there is reason to do so, that should > be explained in eselect-news. > Thanks for the feedback and your input. However, as I said earlier, the information about what kind of ini files were installed on your system is elogged. I expect you to read that, especially when upgrading your software on a production machine. > As for using a development version by default, you should not *CHANGE* the > configuration on users without their consent. > We did not. You installed a new slot and thus you got the default settings we ship with PHP. Even if we did ship our version of the production ini file, you should review those configuration files before completing the upgrade of your production boxes. > Furthermore, the now-default configuration causes numerous other packages (such > as horde) to not work out of the box because of the strict conformance required > by the development config. > If you want to run stuff in production, just switch to the production ini file. The emerge log will tell you how to do that. Thanks.
(In reply to comment #7) > (In reply to comment #6) > > > > You should not rely on everyone reading your blog before upgrading your > > packages. It is unreasonable for everyone to do that every day/week before > > they upgrade their system. Doing 'emerge -uvD @world @system --newuse' should > > *NOT* break a production machine, and if there is reason to do so, that should > > be explained in eselect-news. > > > > Thanks for the feedback and your input. However, as I said earlier, the > information about what kind of ini files were installed on your system is > elogged. I expect you to read that, especially when upgrading your software on > a production machine. That is very unreasonable. So many packages elog so much cruft that is irrelevant. There are a ton of packages which keep printing out "if you are upgrading from ___, do ___" which are not relevant except for the first time, so elog is full of irrelevant information causing relevant information to get lost in the crowd (or simply pushed off the scrollback buffer). I thought this was the whole point of eselect-news. > > As for using a development version by default, you should not *CHANGE* the > > configuration on users without their consent. > > > > We did not. You installed a new slot and thus you got the default settings we > ship with PHP. I think that pretty much fits what I said: I had a production php-5.3. I upgraded, and my system was left with no active php. I selected php-5.3 from 'eselect php' My system had a debug config enabled. This feels to me like breaking production environments with little end-user notification (not even etc-update saw the change because of the different directory used). I would normally investigate further from an x.y to x.y+1 bump, but I'd expect x.y.z to x.y.z+1 to not have such a drastic change. > Even if we did ship our version of the production ini file, you > should review those configuration files before completing the upgrade of your > production boxes. Define "completing the upgrade" ... All I did was 'emerge -uvD @world @system --newuse' and was left with no php enabled and the only available config in 'eselect php' did not match what I had before. > > > Furthermore, the now-default configuration causes numerous other packages (such > > as horde) to not work out of the box because of the strict conformance required > > by the development config. > > > > If you want to run stuff in production, just switch to the production ini file. > The emerge log will tell you how to do that. I've done that. This bug is not to fix my particular box as I'm capable of editing config files myself; this bug is to fix the core of the problem: production by default. Another bug is already open to address the "no version of php enabled after upgrade" bug.
You cannot expect that emerge -uavDN world doesn't break your system. E.g with the old ebuilds, you would have to rebuild all pecl extensions if you upgraded from PHP 5.2, with python you have to run python-updater and in many other cases you have to run revdep-rebuild. Switching from development to production ini files by default is as easy as adding a line to /etc/make.conf, and then you do not have to think about that problem again. I won't heed arguments such as "there is too much cruft in the elog to read it". We do not put information there for fun. I still see no compelling reason for switching what the default ini file.
(In reply to comment #9) > You cannot expect that emerge -uavDN world doesn't break your system. E.g with > the old ebuilds, you would have to rebuild all pecl extensions if you upgraded > from PHP 5.2, with python you have to run python-updater and in many other > cases you have to run revdep-rebuild. Right, but those are well documented and publicized situations. Furthermore, @preserved-rebuild replaces the need for revdep-rebuild in most circumstances. > > Switching from development to production ini files by default is as easy as > adding a line to /etc/make.conf, and then you do not have to think about that > problem again. Right, I know that that's all *I* need to do, but this bug is not about solving my problem, it's about doing "the right thing" so your users don't get hit by this problem. > > I won't heed arguments such as "there is too much cruft in the elog to read > it". We do not put information there for fun. Well then do something about making it more accessible. If someone emerges 50 packages and your message is past the scrollback buffer, how do you expect users to see that message? It is my understanding that eselect-news exists for exactly this problem! > I still see no compelling reason for switching what the default ini file. Well what was your compelling reason for switching from production default to development default? The fact that production environments are quickly evaporating from your user base?
(In reply to comment #10) > (In reply to comment #9) > > > I won't heed arguments such as "there is too much cruft in the elog to read > > it". We do not put information there for fun. > > Well then do something about making it more accessible. If someone emerges 50 > packages and your message is past the scrollback buffer, how do you expect > users to see that message? It is my understanding that eselect-news exists for > exactly this problem! > How about using `eread' from gentoolkit? > > I still see no compelling reason for switching what the default ini file. > > Well what was your compelling reason for switching from production default to > development default? The fact that production environments are quickly > evaporating from your user base? > 1. We have more users who want development ini files (based on feedback) 2. Those who use PHP in production are generally more skilled than those using it for development 3. Those who own production systems are expected to be more careful, especially that they read the ebuild log. Preferably that they also take a look at their configuration before they restart apache or fpm or whatever.
