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?
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?
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 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.
Brian
