Pre-ITP: apache/mod_php

[Brian Dessent <brian at dessent dot net>]

I think I have finally worked out the kinks in the crappy PHP build
system.  I managed to banish that awful "mkdll.sh" business.  The
results after "make" are simply cygphp4.dll and the php4_*.dll ready to
be used.  Oh, and none of that rebasing hassle seems to be required. 
Cheers to whatever binutils/gcc changes that made that one possible.

I can now cleanly build PHP 4.3.8 as an Apache DSO with the following
modules/extensions:

A) Internal / Built-In:
ctype, mime_magic, overload, posix, session, sockets, standard,
tokenizer	

B) Compiled in cygphp4.dll (bundled libs) / won't work shared:
bcmath, calendar, dba (gdbm, cdb, cdb_make, inifile, flatfile), dbase,
dbx, dio, exif, filepro, ftp, mysql, pcre, xml

Note however: xml uses to system expat and gdbm uses to system gdbm. 
The other dbm's could also be added (Berkeley db 4.x, 3.x, 2.x) but they
didn't work right out of the box and would require more m4 patches so I
didn't bother.  I left the pcre as the PHP bundled lib as the config
option for it is very scary and says you should only switch to system
pcre if you really know what you're doing.  :-)

C) Fully shared (activated in php.ini and dlopen'd from a DLL):
bz2, curl, domxml, gd, gettext, gmp, iconv, imap, ldap, mcrypt, openssl,
pgsql, zlib

Note also: Currently gd is picking up the X11 libXpm, but with some work
it could be told to find the noX version (and add dependency on that
package instead.)  That would at least eliminate a dependency on libX11
for the -gd package, which could save considerable hassle if someone
didn't want any of the xorg stuff.  Or *gulp* I suppose it might be
possible to offer both, I think Debian does this.

Anyway, I'm getting pretty close to being able to ITP a whole slew of
stuff but I'd like to get some opinions on some matters first.  Below
are some issues to consider:

- mysqlclient.  At the moment I'm compiling the "PHP bundled" MySQL
client library, but I think it would be better if Cygwin had mysqlclient
and mysqlclient-devel packages.  That way mod_php could link against
those, and the issue of "no other Apache modules can use MySQL if you
use the bundled php version" is solved.  I'll take a look at packaging
this as well, I've read that the -client packages compile cleanly.  I
don't think the -server side builds clean yet though.

<Aside>
If you like license discussions then this also brings up a bit of
history.  The mysqlclient libs bundled with PHP are version 3.x - they
will still talk to MySQL 4.x however.  This is because the client libs
were LGPL in 3.x, whereas MySQL changed them to GPL for 4.x and on.  For
a while there was panic and confusion because GPL was not compatible
("too restrictive") with the PHP/artistic license, and hence the PHP
devs could not bundle it.  In PHP5 everyone got their panties in a
ruffle for a while because the entire bundled MySQL lib was removed. 
However at some point MySQL AB issued a "open source compatible license
exemption" which allowed the mysql client 4.x libraries to be used in
conjunction with a blessed set of licenses without infecting them with
the GPL.  So, more or less it's a non-issue now.  But for a while there
it was questionable whether you could compile PHP with mysqlclient 4.x
and distribute the result.  Licensing aside I think it would be good on
technical grounds to have a modern mysqlclient lib and not the creaky,
barely-maintained 3.x fork that still remains in the php4 tarball.
</Aside>

- versioning: Apache 1.3 vs 2.x and php4 vs php5.  For apache, I had
planned to just adopt the "apache" = 1.3 and "apache2" = 2.x method.  So
/etc/apache/*.conf, /usr/lib/apache/mod*.dll, /usr/share/apache, etc. 
And when 2.x is ready, /etc/apache2/*.cond, /usr/lib/apache2/*, etc. 
Contrast to Debian which has /usr/lib/apache/{1.3,2.0}.  For php I've
used "php4" throughout, so /etc/php4/*.ini, /usr/lib/php4/*, and so on. 
If/when php5 is ready I think it should co-exist with s/php4/php5/ in
the names.

- Package naming.  We already have "apache" and I was planning on
"mod_php4" for the main PHP module.  Alternatives: libapache-mod_php4,
apache-php4, apache-mod_php4, etc.  Same for mod_ssl and other Apache
modules.  And the question still remains what to call the additional PHP
extension packages, as any of the extensions from the group in C) above
can be made its own package.  So for example we could offer a
"mod_php4-pgsql" package that would add postgres support.  Some of them
though don't really deserve their own package, I mean I think it would
be safe to require bzip2 and zlib and not offer them as individually
selectable modules.

Or, there could just be the single mod_php4 package, but only the
modules from C) that correspond to installed packages are enabled in the
postinstall, so that they don't pull in a bunch of stuff in the
"requires" line.  Under that scenario if you wanted to e.g. add postgres
support you would install the postgres package, then reinstall mod_php4
(or re-run its module config script) and the pqsql module would be
automagically activated.  I can see pros and cons to both ways of doing
it - what do you think?

Also in this category is the CLI version of PHP (which I'm not building
at the moment) as well as PEAR.  They could be offered as seperate
"php4-cli" and "php4-pear" packages.  However I'm not entirely sure how
the extensions would work there: I /think/ but am not sure that they
would share the same extensions (the Apache module and /usr/bin/php4
that is.)

I'm sure there are other issues, but those are the ones that come to
mind right now... I'm just trying to get some concensus here first
before posting "-1" packages that end up needing to be recreated.  All
comments welcome.

Brian