Description of problem: The spec file for PHP5 in Fedora Core and Red Hat Web Application Stack 1.0 Beta doe not include support for building Oracle and MSSQL libraries Version-Release number of selected component (if applicable): php-5.1.2-5 How reproducible: Missing Code Steps to Reproduce: 1. Down load the source RPM 2. try to build new RPMs with the --with oci8 and --with mssql switches 3. Actual results: The library modules (and corrsponding RPMs) are not generated Expected results: These RPMs generated: php-mssql-5.1.2-5.i386.rpm php-oci8-5.1.2-5.i86.rpm Additional info: The spec file for PHP4 includs support for command line switches to allow the creation of RPMs for Oracle and MS-SQL. That support has been removed (not added to?) the spec file for PHP5.
These should be packaged separately, e.g. the PECL package for oci8 is here: http://pecl.php.net/package/oci8
I agree they should produce separate binary packages, but it seems like those packages should still be built as part of the php source RPM. As of at least php-4.3.11-2.8 (FC3) and php-4.3.9-3.15 (RHEL4), support for building the php- mssql and php-oci8 packages was included as an optional part of the php source RPM. Are you saying the intent is to stop including that support in php.spec? This is further complicated by three facts: 1) both the mssql and oci8 extensions require the php5 source in order to build, 2) the mssql extension doesn't appear to be available as a PECL module, and 3) both extensions are already _included_ with the php5 source. For all these reasons, building them within php.spec seems to make the most sense; as far as I can tell, the only alternative would be to have 3 source RPMs containing identical source code. If it would help, I'd be happy to submit a short patch to php.spec to preserve the behavior from the php4 packages.
It really should not be very complicated to produce source RPMs for the oci8 and mssql modules; maybe take a look at some of the PECL modules being packaged for Extras. The options have been removed because we can't support them and can't maintain the code. Shipping them implies an expectation of support which we simply can't meet.