Pre-ITP: apache/mod_php

[Reini Urban]

Brian Dessent schrieb:
> Reini Urban wrote:
>>BTW, brian: /usr/lib/php4 is really not a very good idea, unless you fix
>>phpize and the other scripts also.
>>all of them expect ${prefix}/lib/php/... even in the .in files.
>>please stay with the standards.
> 
> Okay, that's good to know.  I can go back to using /usr/lib/php for
> php4, but what's the "standard" for php5?  /usr/lib/php5?  Surely they
> don't expect you to run one or the other but not both?

that's a problem I avoided so far.
officially they cannot coexist under /usr/lib/php,
but the extension_dir is seperated and the dll naming is versioned.

> How about configs?  I tend to prefer having a directory, /etc/php or
> /etc/php4, under which you have your php.ini-recommended and/or
> php.ini-dist, with a postinstall that copies to php.ini if none already
> exists.  I'd rather not pollute /etc with all that, and worry about php4
> and php5 ini names colliding.  Is there any problem that you see with
> doing it like this?

officially the .ini is at /usr/lib/php/
if we make /usr/lib/php5/ that's okay then.
I never saw it in /etc but I don't know that many distros.
I always compiled my own php into /usr/local/.

it's true that coexistance is crucial.

> Also, I have clearly not put a lot of thought into the CLI/CGI versions
> and PEAR.  However it looks like there could be a lot of path decisions
> there, so I suppose I shouldn't try to put it off for a later release. 
> I'm fine with offering CLI and PEAR, but I have no intention to also
> support a CGI package at the moment.  The typical reason for wanting PHP
> as a CGI instead of a module is so that you can use suexec or other
> similar security tools to cope with multiple user accounts all being
> able to upload .php files.  However, I would not want to trust Cygwin
> for this regardless, so I just don't see it as being a common need.  I
> see it more as filling the "developer testbed" niche, so that you can
> develop your apps locally and then copy them over to your real server
> when done.  I'm sure people will want to use Cygwin/Apache/PHP in
> production, but I'm hoping that it remains a small number of these
> people.

another purpose:
the php5 cgi is so far the best solution to debug php5. (besides with 
non-free debuggers like kommodo and xdebug).
php5 debugging as module has poor support by Zend, it is closed source, 
and the cgi version doesn't need a binary compatible debugging dll. 
that's why I need the cgi for php5 at least.
besides, supporting the CGI target is not really an issue. just one 
additional exe to put somewhere:
/usr/lib/bin/php.exe or /var/www/cgi-bin/php.exe

> Another issue: currently in my setup cygphp4.dll is being put in
> /usr/lib/apache/, with all the other Apache DSOs.  This is not in the
> path by default.  I was under the impression that this does not matter,
> since cygphp4.dll is already loaded by the time that the extensions are
> activated, so the fact that they're linked against it but it's not in
> the path shouldn't matter.  However, if that's not the case and it does
> need to live in /usr/bin then that will complicate the Apache setup
> slightly.   I tend to think it would be better to simply require this
> path added to $PATH of the service if it becomes an issue, rather than
> have Apache modules strewn about more than one place.

you confused me :)
let me explain. cygphp4.dll is the shared master php library (there's no 
/usr/lib/libphp4.a), and there exist various sapi interfaces to 
communicate between the server and the cygphp4.dll.
stipe had just one big /usr/lib/apache/libphp4.dll, which was the apache 
module and the php lib together. the cgi and cli couldn't use it.

the call path is like this:
/usr/sbin/httpd.exe => /usr/lib/apache/mod_php4.dll
/usr/lib/apache/mod_php4.dll => /usr/bin/cygphp4.dll
/usr/bin/cygphp4.dll => <extension_dir>/php_<ext>.dll

/usr/bin/php.exe             => /usr/bin/cygphp4.dll
...
/usr/lib/php/bin/php.exe     => /usr/bin/cygphp4.dll

couldn't you make your gbs and patch avialable somewhere, so that we 
(gerrit and me), can try it out? and try to add as much extensions as 
possible.

BTW: 4.3.9 and 5.0.2 are officially released now.
At least 4.3.9 is a major improvement, since I (phpwiki) was hit by the 
PCRE memory exhaustion bug. There's also GIF support.
-- 
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/