Development (#5) - rpm ファイルのリリース番号の変更 (#1) - Message List
irc でちょっと相談しましたが、rpm のファイル名の命名規則を変更して、Vine Linux 自体のメジャーリリース番号を追加する件について、いくつか案を考えてみました。
%{REL}: プログラム自体のリリース番号 %{DIST}: Vine のメジャーリリース番号 として、
案1. %{REL}vl%{DIST}
例)hoge-1.0.0-1vl5.arch.rpm
案2. %{REL}.vl%{DIST} *fodora風
例)hoge-1.0.0-1.vl5.arch.rpm
案3. %{DIST}vl%{REL}
例)hoge-1.0.0-5vl1.arch.rpm
案4. vl%{DIST}.%{REL}
例)hoge-1.0.0-vl5.1. arch.rpm
ポイントとして、
- Seed > Release に必ずなること
- 今の番号体系との比較でも必ず上位に来ること
- わかりやすいこと
辺りは確実に満足する必要があると思います。
後、他に
- Vine Linux 4.x 環境でのリビルドへの配慮するかどうか
- 命名規則変更後の Seed/Plus 両方への put をどうするか
とかについても考慮しておいた方が良さそうです。
個人的には案の4か2が良さそうに思えますが、どうでしょう?
-
Message #2
まず 1,2 or 3,4 を考えてみます。
基本的には今後作られる/アップデートされるパッケージは全バージョン共通のSPECとなることを前提とすると、パッケージリリースが最初にくる 1 or 2 案がいいと思います。
次に、1 or 2 で考えてみます。
どちらも大きな違いはありませんが、rpmやaptにおける"."の扱いと数字と英字の間にある暗黙のドットなどを考えると、過去の命名方法も踏まえて 1 のほうがいいと思います。
fedoraに似せることで得られるメリットはほとんどなく、fedora等のパッケージがリビルドするだけで使えるように見えるかもしれないことを考えると、やはり 1 ほうがよいと(個人的には)思います。
daisuke2008/01/11 03:05:55 -
-
Message #6
どちらも大きな違いはありませんが、rpmやaptにおける"."の扱いと数字と英字の間にある暗黙のドットなどを考えると、過去の命名方法も踏まえて 1 のほうがいいと思います。
なるほど。
fedoraに似せることで得られるメリットはほとんどなく、fedora等のパッケージがリビルドするだけで使えるように見えるかもしれないことを考えると、やはり 1 ほうがよいと(個人的には)思います。
最初は逆のメリット(番号体系が同じ=ファイル名の意味が理解しやすい)があると思っていましたが、確かにデメリット(fedora等のパッケージがリビルドするだけで使えるように見えるかもしれない)もありますね。
ただ 1 だと今のパッケージでも 1vl5 があり得るので、その辺と被るのがちょっと気になる(*ただしかなり稀なケース)のと、番号体系を変えましたーという点がぱっと見わからないとうか訴求力が無いというか、といった点が気になりますね。
3, 4 より 1, 2 が良いというのは賛成です。
kazutaka2008/01/11 13:30:00 -
-
Message #8
. は使わない方(案1)に1票。すでにvl前の数字に1以上を使っている場合は 単純に+1するだけ(2vl5にする)で問題ありません。(.が入っているからと 言って+1しなくてもバージョン順序の問題が実際に解決するわけではない)
release 番号の付け方の変更がユーザにわかる必要はあまりないと思います。 むしろ必要なら requires で特定のバージョン依存するべきだろうし、開発者 にとっては spec 上で distribution version のマクロが tag として入るこ とになるので、変更されたことはわかると思います。
daisuke2008/01/20 00:20:20 -
-
Message #9
では他の方から異論が出なければ、案1にしましょう。
次に実現方法ですが、マクロ組むとしたら例えばこんなスクリプト
cat /etc/vine-release | awk '{print $3}' | awk -F "\." '{print "vl"$1}'
の結果を %{dist_release} として返すようにしておいて、 spec 中でこれを
Release: 1%{?dist_release}
のようにして使う感じですかね?
一応 VineSeed のパッケージが 4.2 でもリビルドできるように 配慮しておいた方が良さそうですし。
kazutaka2008/01/20 23:12:53 -
-
Message #10
もうちょっと詰めて、ちゃんと動くようにしました。
まず /usr/lib/rpm/macros に以下の2行を追加します。
# Macros to get vine major version %_dist_release %(cat /etc/vine-release | awk '{print $3}' | awk -F "\." '{print "vl"$1}')次に spec で以下のようにマクロを使います。
%define release 0%{?_dist_release}で、これでパッケージを作れば例えば 0vl4 とかになります。
一応?付きで定義しておけばマクロの定義されていない環境でもリビルドできるので、こんな感じで大丈夫だと思います。
もしこれで問題無さそうでしたら、rpm に取り込んでください。 (あとできたら vine-release の更新 4->5 もお願いします)
kazutaka2008/01/28 22:56:53 -
-
Message #11
gawk を使わず coreutils だけにしておくのはどうでしょうか。
%_dist_release vl%(cat /etc/release | cut -f3 -d" " | cut -f1 -d.)
rpm-4.4.2.3 がでてからとおもっていましたが、とりあえず 4.4.2.2 で 入れておこうとおもいます。
これとは別にドキュメントとしてまとめるときには rc や beta などの バージョンの付け方のポリシーも明確にしておいたほうがいいですね。 release の付け方にも影響しますし。0.rc1vl5 や 0.beta1vl5 とかにな るのかとか。
daisuke2008/01/30 03:38:12 -
-
Message #13
gawk を使わず coreutils だけにしておくのはどうでしょうか。
そっちのが良いですね。賛成です。
これとは別にドキュメントとしてまとめるときには rc や beta などの バージョンの付け方のポリシーも明確にしておいたほうがいいですね。 release の付け方にも影響しますし。0.rc1vl5 や 0.beta1vl5 とかにな るのかとか。
こっちは Wiki の方に書いておいたほうが良さそうですね。 時間が取れたらやっときます。
kazutaka2008/01/31 17:37:19 -
-
Message #14
こっちは Wiki の方に書いておいたほうが良さそうですね。 時間が取れたらやっときます。
とりあえず(案)として Wiki に書いておきました。 標準ケースと、rc/beta/pre などが付く場合の2種類を書いておきましたが、他に書いておいた方が良いケースがあれば追記お願いします。
それが決まったら、次はいつから新しいルールに移行するのかと、Vine Plusのパッケージの扱いをどうするのかを決めれば作業に移れると思います。
kazutaka2008/01/31 23:30:00 -
-
Message #15
具体的な案はないのですが、
1. rc無し正式版 > rc付き と確実に認識されるように （これは 0.rcx とすることで考慮済みですね）
2. kernel module package の場合
のパターンは考慮、検証しておくべきかと
iwamoto2008/02/04 12:13:03 -
-
Message #16
2. kernel module package の場合
間に kernel の version_release が入るだけで一緒かな、と考えていたんですが、もしかしてそれだけじゃまずいケースがありそうですか？
kazutaka2008/02/04 23:23:50 -
-
Message #17
security BTS での話題ですが、
http://security.vinelinux.org/kagemai/guest.cgi?project=security&action=view_report&id=253
７番目の鈴木さんのご発言な場合などがあるかと。
iwamoto2008/02/05 09:16:02 -
-
Message #18
７番目の鈴木さんのご発言な場合などがあるかと。
うーむ、これは難しいですね。 確かに kernel-module はバージョン番号が2つ連なるので、途中で桁数がずれたりすると、おっしゃるようなことが起きますね。
とは言え、リリース番号で吸収する問題ではない気もしますし、何か良い方法はないですかね。。。
kazutaka2008/02/05 13:24:58 -
-
Message #20
案ですがいっそのこと、kernel の version_release の位置を変えてしまうというのはどうでしょう?
(現行) kernel-module-madwifi-0.9.3.2_2.6.16_0vl76.13-0vl0.42
(変更) kernel-module-madwifi-0.9.3.2-0vl0.42_2.6.16_0vl76.13
ただし、これを適用すると同じバージョンのままでは、4.2 > Seed になってしまうので、そこはパッケージの更新時に一工夫(?)必要ですが。
kazutaka2008/02/10 16:10:11 -
Message #27
問題提起した人間が言うのもアレですが、kernel-moduleはレアケースと考えて、version 認識の問題が起きたら epoch 使う、ってことでもいい気がします。
個人的には現行の modulever_kernelver という表記方法がわかりやすいですし、#20 のご提案にはなんか違和感を感じます(;
新表記方式に移行する作業をすすめませんか？
アナウンスなども含めて。
iwamoto2008/03/13 12:00:55 -
-
Message #28
新表記方式に移行する作業をすすめませんか？ アナウンスなども含めて。
賛成です。
vine-release や rpm の更新が必要だと思いますが、それにかかる時間を入れても今週末辺りにはアナウンスする、という感じでどうでしょう?
kazutaka2008/03/17 21:42:50 -
-
Message #29
vine-release の修正と rpm の修正はとりあえずできました。 それぞれのバージョンは、 vine-release-5.0-0.0.1vl5.seed rpm-4.4.2.3-0.rc1.1vl5 という感じにしてあります。(これら2つはspec内に%_dist_releaseの設定をしこんであります)
i386->i686 にする方のマクロ調整などは、 とりあえずいまのところはいれていません。
daisuke2008/03/18 00:52:38 -
-
Message #31
それぞれ upload しました。 URLだけははっておきましたが、移行のアナウンスもちゃんとしないと いけませんね。
daisuke2008/03/18 21:13:44 -
-
Message #32
URLだけははっておきましたが、移行のアナウンスもちゃんとしないと いけませんね。
アナウンス確認しました。対応ありがとうございます。
あとは Vine Plus/4.0 (3.x は EOL 近いので除く)にのみ upload する場合や、VineSeed Plus のパッケージを別の人が Vine Plus/4.0 向けにリビルドする場合などに、リリース番号どうするか、をちょっと補足した方が良い気がします。
- 4.2 向けのみのパッケージは従来通り
- Plus/4.0 と Seed Plus の両方向けのパッケージ(別人による Seed パッケージの 4.0/Plus 向けリビルドを含む)は、4.2 環境では .rpmmacros で _dist_release に vl4 を define してビルドする
といった感じでしょうか?
kazutaka2008/03/19 13:30:57 -
-
Message #42
あとは Vine Plus/4.0 (3.x は EOL 近いので除く)にのみ upload する場合や、VineSeed Plus のパッケージを別の人が Vine Plus/4.0 向けにリビルドする場合などに、リリース番号どうするか、をちょっと補足した方が良い気がします。
これについても ML の議論を元に Wiki に反映されたので、一通り整理されたと思います。
後はがんばってリビルド/更新ですねぇ。
kazutaka2008/05/15 13:30:09
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
