Bug 112497 - Current version of php is the cgi version, instead of the cli version
Current version of php is the cgi version, instead of the cli version
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: php (Show other bugs)
1
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Joe Orton
David Lawrence
http://us2.php.net/manual/en/features...
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-12-21 04:03 EST by terry chay
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-01-21 11:05:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description terry chay 2003-12-21 04:03:03 EST
Description of problem:
The Red Hat RPM currently installs the cgi version for no reason.
There are good reasons for it to use the command line version. For
instance, you cannot write to STDERR because it hasn't been defined or
fopened!

Version-Release number of selected component (if applicable):
php-4.3.3-6.src.rpm

How reproducible:
do a "php -v"

Steps to Reproduce:
1. php -v
2. Look at first line () and see if "cgi" or "cli"
  
Actual results:
PHP 4.3.3 (cgi) (built: Oct 21 2003 09:51:55)

Expected results:
PHP 4.3.3 (cli) (...)

Additional info:

There are some serious problems with the php.spec file that Red Hat
uses (no offense). A lot of the patches are no longer applicable and
the build procedure is suspect in its entirity.

For instance, during the build, you build the PHP system twice. This
dates back before PHP 4.2 when some modules couldn't be built unless
it was specified separately as "--enable-cgi". And since PHP 4.2 an
"--enable-cli" was introduced obviating the need for a cgi version of
PHP (you use the PHP Apache SAPI already).

Also, you manually construct the library dependencies in a strange
manner. I guess this dates back a long time ago when libtool was unstable.

I think it would be a good idea to start from scratch with FC1 and
then work out the bugs from there. The RH people have already got what
they believe to be a "stable enough" version of PHP running in RH with
a zillion back patches.

I'd be willing to help maintain this package for FC, but I'm not
familiar with the rules/procedures. If someone can send me e-mail
explaining how to help out (mailing lists, irc, cvs, etc.).
Comment 1 Joe Orton 2003-12-22 05:37:39 EST
Patches: which do you think are "no longer applicable" exactly, and why?

CLI vs CGI SAPIs: thanks for the info, I've been meaning to look into
this.

Building the library dependencies: I presume you are referring to the
LIBS="..." line?  If so, yes, I totally agree: I removed this in the
4.3.4-2 package in Raw Hide a while back.  The latest php source RPM
is available from
http://download.fedora.redhat.com/pub/fedora/linux/core/development/

Helping out: the best way to help out is to file bugs on specific
problems, and attach any patches to the bugs.  The web site has
information on mailing lists: http://fedora.redhat.com/participate/
Comment 2 Joe Orton 2004-01-21 11:05:16 EST
I'm closing this bug since there is no specific issue to be addressed
here.  Please do open bugs on any specific issues you have with the
PHP package!

To clarify: the CGI SAPI is built rather than CLI so that people can
use PHP as a CGI interpreter via shebang lines: this can be used via
suexec, for example, which the CLI version can't AFAIK.  And there is
no way of building the CGI SAPI and an Apache SAPI in a single
configure invocation AFAICT.  Again: please correct me/supply patches
if this is now possible.

Note You need to log in before you can comment on or make changes to this bug.