ports/70220: The new PHP port does not all the inclusion of certain extensions

[Bill Moran]

>Number:         70220
>Category:       ports
>Synopsis:       The new PHP port does not all the inclusion of certain extensions
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Aug 09 16:20:20 GMT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Bill Moran
>Release:        FreeBSD 4.10-RELEASE-p2 i386
>Organization:
Potential Technologies
>Environment:
System: FreeBSD working.potentialtech.com 4.10-RELEASE-p2 FreeBSD 4.10-RELEASE-p2 #3: Mon Jul 26 01:12:57 EDT 2004 wmoran at working.potentialtech.com:/usr/obj/usr/src/sys/WORKING i386


	
>Description:
	The current PHP4 port (lang/php4) adds the --disable-all option to
	CONFIGURE_ARGS.  It appears as though this was done to allow additional
	ports to be made that add modular functionality to PHP 4.
	Unfortunately, --disable-all also disables many features of PHP 4 that
	can not be added as seperate ports.  Two specific examples are pcre
	and session support.  Both of these feature sets are "assumed" to
	be there by the folks who write the PHP docs, and it seems that many
	PHP-based applications expect that they will exist.
	Currently, there is no way to add these back in, except to hack the
	makefile (which seems to defeat the purpose of the port)
>How-To-Repeat:
	Install PHP 4 port, then try to use a script that requires sessions
	or pcre.  Those functions will be unavailable.  Searching for a
	port to add on those functions (php4_pcre would be a logical guess)
	does not yield anything.  I don't think it's possible to create a
	seperate port that adds these features, as they're part of the
	PHP distribution.
	
>Fix:
	I was able to work arond this by hacking the Makefile to specifically
	add '--with-pcre-regex=yes --enable-session' to CONFIGURE_ARGS (after
	the --disable-all).  It's possible that removing --disable-all
	altogether might be a better idea, but I have not tested.
	There are a number of extensions (such as the two examples given)
	that should probably always be enabled, since the PHP team seems
	to assume that they will be, as well as many PHP app developers.
	


>Release-Note:
>Audit-Trail:
>Unformatted: