Toshiharu Harada
harad****@gmail*****
2007年 10月 28日 (日) 23:28:44 JST
07/10/28 に Tetsuo Handa<from-****@i-lov*****> さんは書きました: > > 2. Author は結局どのように表記すればよろしい？ > > [Tomoyo-dev 597] で原田さんは「半田さんのデータのアドレスにしましょうか。」 > > と仰ってますが、具体的なアドレスは私には分かっていませんし、Go or NoGo の > > どっちかが判然としません。さて、最終的にはどの名前とアドレスを記載すれば > > 良いですか？（別に１名じゃなくてもいいです。Tomoyo を何かしら使いたい、と > > 思った方がコンタクトを取れる先です） > > これが明示されたらパッケージ化の申請を挙げたいと思っています。 > 会社のアドレスにすると私の派遣期間の終了とともに消滅してしまうと困るので > 個人のアドレスにしようと思っています。 私がkumaneko ＠ sourceforgeのアカウントのほうが良いと思うのも 同じ理由です。将来のことを考えると、半田さんだけでなく、 特に必要、事情のないところはNTTデータに結びつけないほうが 良いと思っています。 > Report bugs to のアドレスは pengu****@I-lov***** にしますが、 > Author が NTT DATA CORPORATION, Japan. だと変ですか？ kumaneko ＠ sourceforgeからの転送ではなく、ということですね。 > > 3. Debian/Ubuntu については、いちいちパッケージをダウンロードさせずに > > apt repository を作って配布、が良いと思いますが、これは行いませんか？ > > やり方については、[Tomoyo-dev 622] で示唆しています。 > はい、 deb だけでなく rpm もレポジトリを作ってダウンロードできるようにしたいと思います。 > [Tomoyo-dev 369] で独自ドメインを取得していただいてからそのままになってしまっていますが、 > 置き場所を tomoyo.sourceforge.jp にするのか独自ドメインのサーバにするのか決めなければいけませんね。 配布に関する私の考え方は、ディストリビューション対応の パッケージ作成と配布は基本的にディストリビューションを知る方に まかせて、プロジェクトはそれを周知、オーサライズする、のが 良いと思っています。SourceForge.jpにはvanilla kernelのように TOMOYOのベースがあって、それが各ディストリビューションに 展開されていくイメージです。 同じ考え方で、置き場所についても対応者がいないもの、 置き場所がないものをSourceForge.jpで置くのが良いと思っています。 （将来的には、独自ドメインで独自配布用サーバを立てる方向との 意見をいただいています） > ７月の開発者会議の頃、ＮＴＴデータとしてのリリースとコミュニティとしてのリリースを区別するのかどうか、 > 区別する場合には、ＮＴＴデータとしてのリリースは sourceforge.jp の「リリース物件」から > コミュニティとしてのリリースは sourceforge.jp 以外のサーバから > ダウンロードしてもらうようにするのかどうかという話がありました。 確かにありましたが、その後の展開で「データとしてのリリース」と 「コミュニティとしてのリリース」を分ける話は（「1.5の凍結」と合わせ） 実質的に解消しています。 > > 4. spec ファイルはパッチとは別ディレクトリではなかったですか？[Tomoyo-dev 620] > > [Tomoyo-dev 587] では「spec* -> ccs-specs/」と示唆がありますが、実際には > > patches ディレクトリになっています。 > 分ける必要はないと私は考えていますが、分けないと何か不都合な点がありますでしょうか？ スレッドを確認したところ、この議論はやまねさんから「何故ひとつに するのですか？」と問いかけがあったところで終わっていました。 > > 5. FHS 準拠してほしい。[Tomoyo-dev 619, 623] > > /usr/lib ディレクトリは "/usr/lib includes object files, libraries, > > and internal binaries that are not intended to be executed directly > > by users or shell scripts. " なので、名前が衝突しないように、という > > 理由だけであるならば使い方が違うと思います。 > > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGANDPA > > > > prefix を付けるなどして対応は出来ないものでしょうか。 > これは ccs- という prefix を付けることで /usr/sbin などに置けると思います。 > しかし、今までは prefix 無しの状態で使用してきたため、 > prefix を追加することはユーザにとってコマンド名の変更を迫ることになるので > なるべく避けたいと考えています。 > やまねさんの判断で deb パッケージでは > /usr/sbin/ccs-editpolicy -> /usr/lib/ccs/editpolicy のようなシンボリックリンクを > 含めるようにしていただいて構いません。 蒸し返したということではないのですが、ccs-toolsの種類 （必須、ユーティリティ、サンプル）を分けるという話も 出ていましたが、議論が閉じていませんね。 （絶対こうでないといけない、というわけではありませんが、 閉じていない議論があるのは気持ち悪いです） -- Toshiharu Harada harad****@gmail*****
TOMOYO
Fork