Yukinobu Hamuro
hamur****@adm*****
2004年 2月 2日 (月) 13:01:31 JST
羽室です >> includeファイルは実行時には全く利用しません(コンパイル時のみ利用)。 > >ということであればrpmのパッケージ的には >musashi-develなどのサブパッケージにまとめてしまう方が良いでしょうか? >(header類全部) なるほど、そういうことになりますね。 srpmではサブパッケージはないですよね。 >> よってrpmでの確認では、動作チェックもOKという意味です。 > >turboでは動作しているのですね。 はい、Turbo7では問題なく動作しております。 >ならば実質はheaderの置場は無害と考えてもいいのでしょうか。 はい、動作についてはまったく無害です。 ># musashiのAPI開発とかしない限り... 「MUSASHIのAPIを用いた開発をしない限り」です。 >> >sf.jpで各種RPMSを配布するのが本当に良いのか >> >また疑問になってきました... >> まちのさんが最適とお考えの配布方法について詳しく教えていただけますか？ > >これは前にも触れましたが、 >パッケージである以上は、その環境に依存します。 >BSDのportやgentooのportageの様にbuildは常に手元で行うモノならば >できあがるバイナリは必ず自分の環境で動作するはずですが... > >RPMであれdebであれ、作られた環境からの依存関係からは >逃れられません。 > >なので、バイナリ形式で公開するには >本来はbuild環境の制約の元で配布しないと >動かないという問題は必ず起こります。 > >結局は、誰かが自分の開発環境で作ったパッケージを >責任持ってメンテナンスできるかどうかという点です。 > >例えば、仮にturbo7のRPMで不具合が起こった場合は >羽室先生のところで修正できるでしょうが、 >turboのエンタープライズ版で同じパッケージを使って不具合が生じた場合に >誰が対応できるかとなると?です。 はい、よくわかります。 >sf.jpで各ユーザからのパッケージ提供を受けた場合も >そのパッケージに不具合があった場合の対応をどうするか、 >as is公開として元パッケージ作成者の判断まかせにするか、 >パッケージ提供の前提条件としてメンテナンスをある程度責任持ってもらうか、 >などの事も考えられます。 > >> いずれにしましても、私としましてはsf.jpにはtarボールのみUPしますので、後はまちのさんにお任せできればと思っておりますが。 > >はい、一度承諾した以上は >できるだけの事をしようと思います。 まちのさんにあまりご負担にならない程度でお願いします。 >ただ、ここであまりこの件にかんして >意見など反響がほとんどないので、ユーザとしては >特にパッケージでなければダメだという認識でもないのかな >と考えて居ります。 >羽室先生の力作のインストールガイドもありますから... でも私の知る限りでは、rpmによる一発インストールの要望は高いと思います。 インストールガイドを読まずインストールできるのがユーザにとっては理想かなと。。。 いろいろとありがとうございます。 本当に助かります。 お忙しいとは思いますがよろしくお願いします。 ---- Yukinobu Hamuro hamur****@adm*****
