[Momonga-devel.ja:01187] PHPバイナリの処方

[Yasuo Ohgaki <yohgaki@xxxxxxxxxx>]

大垣です。

まずは前置きから。
PHP4.3.0からphpという名前のバイナリが二つできます。
私はこの仕様には大反対なのですが、なってしまった物は仕方ありませ
ん... 一つはCGI用のバイナリ、もう一つはコマンドライン用のバイナ
リ(CLI)です。CLIはPHP4.3.0までは、EXPERIMENTALでしたが、
PHP4.3.0からは一応STABLEになっています。

UNIX系OSでは sapi/cgi/php と sapi/cli/php にビルドされま
す。Windowsバイナリ配布版ではCGIバイナリがアーカイブのルートに、
CLIバイナリがcliディレクトリに同じファイル名（php.exe)で配布
されています。
# PHP 4.2.xのWinバイナリではcliはphp-cli.exeとしてアーカイ
# ブのルートに置いてありました。

この二つのバイナリの主な違いや問題点は
・CLIはCGIのが初期化するCGI環境変数などを全く初期化しない
・CLIはCGIが送信するHTTPヘッダを全く送信しない
・CLIにはphp.iniを完全にバイパス（読み込まない）オプション-n
  があるがCGIにはない
・ディレクトリ読み込みなどの関係でCGIで作成(php -q -C など）
  したスクリプトがCLIで実行できない場合がある。CLIには-C(ディ
  レクトリをスクリプトがあるディレクトリにchdirする）オプショ
  ンがない。
・CLIはphp.iniの設定に関わらず、$argvなどを初期化するが、CGI
  はphp.iniの設定に左右される
・CGIはWebサーバー用のphp.iniに設定されている場合が多く、通常
  のスクリプト実行には適さない設定になっている場合が多い。また、
  前述の通り-nオプション（php.iniを読み込まないオプション）も
  ない
・CLIはechoやprintでいちいち不必要な出力のフラッシュを強制的に
  おこなっているが、CGI（とその他全てのSAPI）は行なっていない。
  (プロンプトが必要なアプリケーションの互換性が損なわれる。不必
  要なフラッシュを行なう間抜けなスクリプトが予期せずかける）

などがあります。

一見して、このような状態でリリースするのは混乱する事が明白と思う
のですが、こうなってしまいました。

# 4.2.xではCLIとCGIが同じバイナリ名だったので、phpとphp-cgi
# と命名してインストールするパッチを提案してビルドシステム全体を
# 書いた人がマージしてくれたのですが、PHP4.3.0リリース直前に
# "Windows(多分IIS)でCGIのバイナリ名を変更するのは大変だから
# 名前変更は困る" という方いて議論になり最終的に同じ名前にする
# という事になってしまいました。

php開発者のMLにMandrakeのパッケージャーの方からこのようなメール
がポストされています。要旨はCGIとCLIをそれぞれ、php-cgi、php-cli
としてインストールし、php symlinkを作る。CGIのみインストールさ
れている場合はphp symlinkはphp-cgiへリンクし、CGIとCLIの両方
またはCLIのみインストールされている場合はphp symlinkはphp-cli
へリンクする、という事です。

私としては、上記のような問題を考えて、CLIはphp, CGIはphp-cgi
をして/usr/binにインストールするようにしたい、と考えています。

ご意見がある方は、コメント頂ければ幸いです。

--
Yasuo Ohgaki

====== Message from <jmdault@xxxxxxxxxxxxxxxx> ========
Le sam 04/01/2003 a` 18:13, Marcus Bo"rger a e'crit :

> What might happen is that CLI becomes widely accepted and scripts
> calling php from shebang lines. Id so your above solution is a bad idea
> and i hope CLI will be...


I'm CC'ing the maintainers of PHP for most distributions of Linux, so we
can all be in sync. For those that don't know the issue, I'll resume it
by saying that with PHP 4.3, there is a new CLI (command-line interface)
that complements the CGI interface. The problem is, both files are named
"php".

Here is the solution that I have been experimenting over the past few
days, and that will be implemented in Mandrake Cooker (and soon 9.1):

- There will be two RPMS: php-cli and php-cgi.
- Both packages will provide php
- Using the "update-alternatives", each package will contain
 /usr/bin/php as a symlink to the respective binary. This lets us give a
priority to which binary is called for a given symlink. php-cli will be
given priority 20 (higher), php-cgi will be given priority 10 (lower)
- If only one package is installed, /usr/bin/php will link to the right
executable.
- By default, php-cgi will be installed, in order to maintain backwards
compatibility.
- Users will be able to install the CLI using rpm -i php-cli
- If both packages are installed, php-cli will be called since it's
higher priority.
- All packages that specifically require the command-line interface
(there is none for the moment, but there will be in the future), will
explicitely require php-cli.

This setup means that we don't break the configuration of people that
already have the php CGI interface, while, with one simple command, the
new PHP command-line enthusiasts will be able to have their cake.

This goes with the PHP source approach:
By default, "configure/make/make install" compiles the CGI interface,
and then you have to "make install-cli" to get the CLI.

We just replace the "make install-cli" by "urpmi/apt-get php-cli".

Comments/Questions/Suggestions welcome.

Jean-Michel Dault
PHP/Apache packager
Mandrake Linux