Satoshi MACHINO
machi****@yendo*****
2004年 2月 2日 (月) 12:23:17 JST
まちの です。 On Mon, 02 Feb 2004 10:50:07 +0900 Yukinobu Hamuro <hamur****@adm*****> wrote: > includeファイルは実行時には全く利用しません(コンパイル時のみ利用)。 ということであればrpmのパッケージ的には musashi-develなどのサブパッケージにまとめてしまう方が良いでしょうか? (header類全部) > よってrpmでの確認では、動作チェックもOKという意味です。 turboでは動作しているのですね。 ならば実質はheaderの置場は無害と考えてもいいのでしょうか。 # musashiのAPI開発とかしない限り... > >sf.jpで各種RPMSを配布するのが本当に良いのか > >また疑問になってきました... > まちのさんが最適とお考えの配布方法について詳しく教えていただけますか? これは前にも触れましたが、 パッケージである以上は、その環境に依存します。 BSDのportやgentooのportageの様にbuildは常に手元で行うモノならば できあがるバイナリは必ず自分の環境で動作するはずですが... RPMであれdebであれ、作られた環境からの依存関係からは 逃れられません。 なので、バイナリ形式で公開するには 本来はbuild環境の制約の元で配布しないと 動かないという問題は必ず起こります。 結局は、誰かが自分の開発環境で作ったパッケージを 責任持ってメンテナンスできるかどうかという点です。 例えば、仮にturbo7のRPMで不具合が起こった場合は 羽室先生のところで修正できるでしょうが、 turboのエンタープライズ版で同じパッケージを使って不具合が生じた場合に 誰が対応できるかとなると?です。 sf.jpで各ユーザからのパッケージ提供を受けた場合も そのパッケージに不具合があった場合の対応をどうするか、 as is公開として元パッケージ作成者の判断まかせにするか、 パッケージ提供の前提条件としてメンテナンスをある程度責任持ってもらうか、 などの事も考えられます。 > いずれにしましても、私としましてはsf.jpにはtarボールのみUPしますので、後はまちのさんにお任せできればと思っておりますが。 はい、一度承諾した以上は できるだけの事をしようと思います。 ただ、ここであまりこの件にかんして 意見など反響がほとんどないので、ユーザとしては 特にパッケージでなければダメだという認識でもないのかな と考えて居ります。 羽室先生の力作のインストールガイドもありますから... -- Satoshi MACHINO <machi****@yendo*****> <machi****@vinel*****> GnuPG Fingerprint = 815A FA0C 973D AF3C C9EA 7B9B 8D84 8CD3 6B4F BF32