Re: Pre-ITP: apache/mod_php

[Igor Pechtchanski <pechtcha at cs dot nyu dot edu>]

On Thu, 23 Sep 2004, Brian Dessent wrote:

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

Wow.  Good news.  Thanks for doing this.

> 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

This may be a naive question, but why can't they work as shared libs?
I've found that the main problem with dlopen()ing shared libs that depend
on other shared libs is that the other shared libs have to be in the PATH.
Is there anything beyond that that's required?

> 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.  :-)

Well, you're obviously getting there. :-)

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

Umm, frankly, I see no reason to have apache (a daemon serving external
clients) depend on X.  Does gd use libXpm for anything other than image
conversion?  If not, I'd go with the noX version.

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

A separate package would be nice.  Did I say "thanks for doing this" yet?

> <Aside>
> If you like license discussions then this also brings up a bit of
> history.
> [snip]
> So, more or less it's a non-issue now.
> [snip]
> 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>

By all means, if you have the inclination, please go with the newest
stuff. :-)

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

I like this one.  It'll keep existing installations happy, and isn't
sufficiently different from other layouts to matter much.  One could
imagine adding a "/usr/lib/apache -> /usr/lib/apache2" symlink in a
postinstall script (if /usr/lib/apache isn't present), and teaching setup
to properly remove symlinks before creating directories (something it
should do anyway) if the user decided to install "apache" afterwards.

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

Since setup doesn't support subcategories, an artificial grouping using
the "apache-" prefix is preferable (unless the package truly is
independent).  I'd also prefer "apache-mod_php4" to "apache-php4", since
it reflects what other distributions call it, and allows a separate
distribution of command-line php4 with CGI bindings for apache as
"apache-php4".  Since setup is now resizable, don't worry too much about
longer package names.

Oh, and it's ok to require things like zlib and bzip2.

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

It would certainly be easier to have this setup with apache2 (which pulls
in separate config files from a given directory, rather than having a
monolithic httpd.conf).  For apache 1.3 I'd say it's not worth the bother.

> 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 think setup is about due for a subcategory patch...  Any volunteers? ;-)

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

Again, thanks for doing this work, Brian.  You're really justifying that
gold star you have for taking over Apache.
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"Happiness lies in being privileged to work hard for long hours in doing
whatever you think is worth doing."  -- Dr. Jubal Harshaw