These days after all the cleanups, the "php" package (vs php-common) pretty much just contains Apache HTTPD-related stuff:
# rpm -ql php /etc/httpd/conf.d/php.conf /usr/lib/httpd/modules/libphp5.so /var/lib/php/session /var/www/icons/php.gif
So in theory it should be OK to remove this if you need PHP but not the HTTPD stuff (for example if you are using CGI or CLI only).
However, you'll notice /var/lib/php/session in the above list. This doesn't seem to be specific to HTTPD and indeed is useful if you are using php-cgi from a webserver. Indeed, the path is compiled into the binaries; for example:
$ php-a Interactive shell
php > echo ini_get('session.save_path'); /var/lib/php/session
So I think we should probably move it to php-common - what do others think?
Tim
On Wed, Jul 18, 2007 at 03:08:44PM +0100, Tim Jackson wrote:
However, you'll notice /var/lib/php/session in the above list. This doesn't seem to be specific to HTTPD and indeed is useful if you are using php-cgi from a webserver. Indeed, the path is compiled into the binaries; for example:
$ php-a Interactive shell
php > echo ini_get('session.save_path'); /var/lib/php/session
So I think we should probably move it to php-common - what do others think?
The directory needs to be chgrp apache, so the containing package really needs the "Requires(pre): httpd" to ensure that user exists. So having php-common require httpd defeats the point of the split.
It's a hard problem because the permissions under which php-cgi might be executed are not really predictable. What if it's used with libghttpd, or httpd and suexec, etc...
joe
Joe Orton wrote:
On Wed, Jul 18, 2007 at 03:08:44PM +0100, Tim Jackson wrote:
/var/lib/php/session So I think we should probably move it to php-common - what do others think?
The directory needs to be chgrp apache, so the containing package really needs the "Requires(pre): httpd" to ensure that user exists.
Hmm, yes, I'd forgotten about the ownership issue. That's a tricky one.
It's a hard problem because the permissions under which php-cgi might be executed are not really predictable. What if it's used with libghttpd, or httpd and suexec, etc...
Quite. Oh well, perhaps it is in the best place it can be, then...
Tim
php-devel@lists.fedoraproject.org
-
Joe Orton -
Tim Jackson