Toshiharu Harada
harad****@gmail*****
2007年 7月 31日 (火) 07:33:18 JST
開発者ではないのですが、一票投じます。 07/07/31 に Kensuke Nezu<nez****@samba*****> さんは書きました: > 根津です。 > > Tetsuo Handa wrote: > > そこで、「1.4.2-pl001」という形式でバージョン番号を付与する場合について相談です。 > > > > (1) fs/ccs_common.c 中のバージョン表示を現在の > > printk("TOMOYO: 1.4.2 2007/07/13\n"); > > から > > printk("TOMOYO: 1.4.2pl001 2007/XX/XX\n"); > > のように pl 番号を含めるのでしょうか？ > > （ pl 番号を含めると fs/ccs_common.c が毎回更新されることになってしまいます。 > > 誤って古い pl 番号でコミットしてしまうミスが続発しそうです。 > > > > それは、ソースが汚いですねえ。 > kernelのバージョン付与みたいにMakefileの中で値を変更して、それを元に > TOMOYO_VERSIONみたいなマクロを定義して展開するようにすべきでしたねぇ。 これは今からでもそうしたら良いと思います。 ちなみに、本件については昨日も話し合いましたが、 半田さんがこだわっているのは、「直接」（起動時にバージョン名を 表示する）ccs_common.cのコードの中に、バージョン名を 埋め込みたいという点であり、懸念しているのは要するに 今までは間違いなく自分がその表示バージョンを編集して リリースしていたが、共同開発することによりそこに間違った バージョン名が含まれることです。 > > (2) 全ディストリビューションで同じソースコードを使うように > > 開発しているので、この規則に従うと > > > > kernel-2.6.21-1.3128.fc7_tomoyo_1.4.2-pl001 > > kernel-2.6.22.1-27.fc7_tomoyo_1.4.2-pl002 > > linux-image-2.6.18-12etch1_tomoyo_1.4.2-pl003 > > linux-image-2.6.18-12etch2_tomoyo_1.4.2-pl004 > > kernel-2.6.22.1-33.fc7_tomoyo_1.4.2-pl005 > > > > のように（個々のディストリビューションだけを見ると） pl 番号が不連続になりますが、 > > 不連続になっても構わないのでしょうか？ > > そういうものだ・・・ということでいいんじゃないですかねぇ・・・。 > 元々、kernelバージョンだって、2.6.9-XX は連続しないですから、 > 多分それに違和感をもつ人はいないんじゃないかと・・・。 同感です。 > > (3) rpm の場合は spec ファイルの中でパッチファイルの所在を指定する必要があります。 > > ファイル名が ccs-patch-1.4.2-pl001.tar.gz のような規則だと > > 何れか１つのカーネルがアップデートされた場合に、 > > それに同期して全ての rpm ディストリビューションの spec ファイルの内容を > > 更新しなければいけなくなりますが、それで構わないのでしょうか？ > > それはそういうもの・・・、もしくはrpmの作者がccs-patch-1.4.2-pl001.tar.gz > をccs-patch-1.4.2-pl001-to-pl002.tar.gzを作って複数のパッチアップをしていく > とかそういう風にパッケージャが工夫するところのような気もします。 ここはパッケージャの作業がわかってないのでコメントは控えます。 > > (4) バグフィックスや機能追加を反映させる手間が増えてしまいますが、 > > pl 番号を連続したものにするために > > ディストリビューション毎にソースを分けて管理するのはどうでしょうか？ > > 連続している必要はないと思いますが・・・ｗ ディストロ毎に連続している必要はないと思っていますし、ディストロ毎に ソースを分けて管理するのは運用として間違っていると思います。 > > (5) pl 番号として subversion のコミット番号を使うのはどうでしょうか？ > > コミット単位でplが上がる意味はどこにあるとお考えでしょうか？ 半田さんのポイントは、おそらく「グローバルでユニーク」ということだと 思いますが、私はpl（相当）番号にコミット番号を使っているものを 見たことがなく、それはちょっと変ではないかと思います。 -- Toshiharu Harada harad****@gmail*****
TOMOYO
Fork