Upgrading php with apache2 USE flag makes direct changes to /etc/conf.d/apache2 file. This happens if you DON'T have PHP5 activated in the APACHE2_OPTS. In my case the line changed is: OLD: APACHE2_OPTS="-D SUEXEC" NEW: APACHE2_OPTS="-D SUEXEC -D PHP5" Using ebuilds SHOULD create ._cfg0001_apache2 and not change users configuration without user intervention. The whole change isn't strictly necessary as the user is given information what to do. The problem is this line in php-5.2.12.ebuild php-select apache2 php5 $ USE=apache2 emerge -u dev-lang/php .... * * To enable php, you need to edit your /etc/conf.d/apache2 file and * add '-D PHP5' to APACHE2_OPTS. * * * Configuration file installed as * /etc/apache2/modules.d/70_mod_php5.conf * You may want to edit it before turning the module on in /etc/conf.d/apache2 * Apache conf.d file updated. For this change to take effect, you must restart the Apache webserver using this command: /etc/init.d/apache2 restart ...
Happy 300000th bug! :D
Gentoo has grown pretty well :)(In reply to comment #1) > Happy 300000th bug! :D > Gentoo has grown pretty well :)
Uhm, this is by design - you can't have two packages installing the same file overwriting each other on upgrade/re-emerge. /etc/conf.d/apache2 belongs to www-servers/apache, not to dev-lang/php. And it's a bad idea security-wise as well - if you don't enable php in apache, you'll get the PHP files served by Apache as plaintext, possibly including stuff which contains sensitive information. And users will start filing bugs such as Bug 127645 because we've broken PHP by default.
(In reply to comment #3) > Uhm, this is by design - you can't have two packages installing the same file > overwriting each other on upgrade/re-emerge. /etc/conf.d/apache2 belongs to > www-servers/apache, not to dev-lang/php. > > And it's a bad idea security-wise as well - if you don't enable php in apache, > you'll get the PHP files served by Apache as plaintext, possibly including > stuff which contains sensitive information. And users will start filing bugs > such as Bug 127645 because we've broken PHP by default. > Anyway this is a bad design. Say I have /etc/conf.d/apache2 like APACHE2_OPTS="-D QQQ -D QAZ" APACHE2_OPTS="${APACHE2_OPTS} -D ZZZ -D ZAQ" Then this got changed to APACHE2_OPTS="-D QQQ -D QAZ -D ZZZ -D ZAQ -D PHP5" APACHE2_OPTS="-D QQQ -D QAZ -D ZZZ -D ZAQ -D PHP5" While this is really not what I want. If you are concerned about security: just ebeep for 10 seconds and print red hot warning.
(In reply to comment #4) > If you are concerned about security: just ebeep for 10 seconds and print red > hot warning. Summary - you can't satisfy everyone. See the bug I linked, don't really understand what exactly are you expecting here. People want working stuff out of the box, don't read warnings, don't care about ebeeps and don't want to manually enable every single PHP extension or apache module. If you install mod_php, then you presumably want to use it, otherwise there's no point in installing it.
(In reply to comment #5) > (In reply to comment #4) > > If you are concerned about security: just ebeep for 10 seconds and print red > > hot warning. > > Summary - you can't satisfy everyone. See the bug I linked, don't really > understand what exactly are you expecting here. People want working stuff out > of the box, don't read warnings, don't care about ebeeps and don't want to > manually enable every single PHP extension or apache module. If you install > mod_php, then you presumably want to use it, otherwise there's no point in > installing it. Well, I've saw that bug. I agree, that there are a lot of options to install and configure apache with modules, and now understand the decision chosen. So let's modify it slightly to fit some more use cases. I propose to change /usr/share/php-select/libapache.sh from app-admin/php-toolkit to either: 1) backup original /etc/conf.d/apache2 to something like /etc/conf.d/apache2.orig 2) modify /etc/conf.d/apache in-place, but save original "APACHE2_OPTS=.*" as a commented line: "# APACHE2_OPTS=.* # before dev-lang/php" 3) add the following line to the buttom: APACHE2_OPTS="${APACHE2_OPTS} -D PHP5" Also I propose /usr/share/php-select/libapache.sh to ignore commented lines
Bug 127645 was based on this use case: "Down the road, apache is upgraded and during etc-update, /etc/conf.d/apache2 is accidently reverted to stock (no extra modules enabled). What happens now Apache is restarted, and mod_php is not loaded. The site now proceeds to serve up .php source code directly. And in the case of MediaWiki, the database passwords are available to all (the bad design of mediawiki is besides the point)." This is clearly a user error, and I see no reason why Gentoo should support this use case. dev-lang/php shouldn't touch files belong to www-servers/apache @Doktor Notor, Of course we can't satisfy everyone. The key here is whether we want to satisfy the Gentoo crowd or the Ubuntu crowd. If you want to satisfy the later, you might as well trigger a /etc/init.d/apache2 restart after emerging php (that's what Ubuntu really does).
I providing php by fcgi and suexec and -D PHP5 broking my web serwer... -D FCGI + -D PHP5 doesn't work, and administrator using etc-update don't see changes in /etc/conf.d/apache and searching problem in another files.. I spent 3days before I checked file that shouldn't be modified.. this information is not included in portage info after merge.. its should be providing by etc-update.. or this file couldn't be modyfied after reinstall or upgrade sorry for my poor english ;-)
While adding -D PH5 automatically may be seen as a measure of protecting users, it is not really the Gentoo way. Once we move away from php-toolkit, this behaviour will cease and you will have to manually have to add -D PHP to /etc/conf.d/apache2.
*** Bug 342063 has been marked as a duplicate of this bug. ***
Fixed now. No more php-toolkit
