Subject: Need feedback for PHP4 update to 4.0.6
To: None <firstname.lastname@example.org>
From: Johnny Lam <email@example.com>
Date: 10/08/2001 22:53:37
I've been working on an update of www/php4 to the latest released version
4.0.6. I intend to make the following changes:
* www/php4 will contain only the base package with _every_ extension
_not_ compiled in.
Our current package has this puzzling mix of extensions compiled into php4:
xml, wddx, gettext, dbase, filepro, gdbm. Future releases may add or remove
modules. Also, the whole design of PHP is so that there is no real "base"
functionality -- everything can be compiled as a shared module extension.
Rather than have a php4 package that has a changing set of dependencies,
I want to make www/php4 depend on nothing, and add extra functionality as
modules by making additional php4-* packages.
* A fairly comprehensive set of php4-* extension module packages will
be added to pkgsrc.
These modules come from the php-4.0.6/ext directory and are compiled as
shared modules. I'm going to add all of the extensions marked as "working"
or "maintained", plus a few that are marked as "experimental". I can add
them all, but I don't have a lot of the software requirements, so some of
those packages would be untested. However, that's something that can always
be done later.
* The php4-* module packages will be moved to appropriate catagories
and not all lumped into www.
Our perl modules are spread throughout the tree in relevant categories. I
think our php4 modules should do the same.
Packages that need specific functionality from PHP4 will now directly
specify the modules that they require. I see this as a good thing, e.g.
the use of php4-gettext will be made explicit instead of being assumed,
since the gettext API extension isn't really a part of PHP4.
The above explanation is also the rationale for closing pkg/13764
(options to php4 pkg disabling prce) by firstname.lastname@example.org.
Lastly, I'm attempting to fix pkg/13743 (ap-php4 is badly linked and this
causes php4-sablot to fail at run time) by email@example.com. The suggested
fix in the PR was that ap-php4 should be linked with libgcc.a so that some
C++ references will resolve correctly. The new php4 and ap-php4 will link
libgcc.a with the -whole-archive flag. In my tests, I had apache load
mod_php4.so, /etc/php.ini contain extensions=sablot.so, and I was able to
start httpd successfully and serve a "Hello, World!" PHP script.
I'd appreciate some feedback as to whether the above changes are good or
bad and why.
-- Johnny Lam <firstname.lastname@example.org>