Skip to main content

ログ取得ツール (移転先予定地)

来週の新製品:ソースバイナリパッチパッケージ形式

小さなパッチを当ててコンパイルして入れる…だけだとパッケージシステムで矛盾してしまうことになりかねない。

そこで、私はソースパッケージを持ってきて*.specファイルをいじってそのパッチ入りのパッケージにしてインストールする…という手順をいつも踏んでいる。これが、非常に面倒である。かと言って/usr/local以下に手コンパイルバイナリを入れる方法もあるが、これは昔やって破綻して懲りた。

で、今やっている「パッケージ+小さなパッチ」→「パッケージ」化の作業を自動化できないかな、と思った。バイナリからソースへのポインタが張ってあれば、ソースにパッチを当ててリビルドしてバイナリを実行できる場所に置く…というのが自動化できるような気がする。

つまり、/bin/lsへのパッチがあったのでユーザがそれを当てたくなったとして、/bin/lsはcoreutilsとかfileutilsに入っているものなので…というのを検索して(rpm -qfで可能)、coreutilsやらfileutilsのソースを見つけだしてパッチを当てて再コンパイルしてできたバイナリをインストールしてパッケージシステムに登録する…というのを自動化できると思ったのだ。…「つまり」以下が余計にわかりにくくなっているが(笑)。

けっこう画期的な気がする。ユーザからの見た目はバイナリパッチのようであって、中身がソースパッチであることを隠蔽するのだ。

実装方法としては、rpmbuildコマンドを改造して、コマンドラインだけで*.src.rpmや*.specにパッチを追加できるようにするのがいいかなぁ。rpmbuildよりも上位でやったほうがいいかな。悩ましい。

でも、小さなパッチをあっちこっちで作って配っているという文化じゃなくなってるんだよね、最近は。残念なことだ。

まあ「パッチ」とさかんに言っているが本命はバージョンアップだ。software-0.1-1.{nosrc,src}.rpmとsoftware-0.2.tar.gzからsoftware-0.2-1.{src,i686}.rpmを作る、というのを自動化できるだけでだいぶ違うと思うんだよな。自分でバラしてsoftware.specの中身をいじってrpmbuild -bb software.specして、rpm -Uvh software-0.2-1.i686.rpmする、というのを、rpmbuild –rebuild software-0.1-1.src.rpm –withver=0.2 –installとかだけで実行できれば労力は激減するだろう。

(追記) 2004-03-10 14:09

そういう意味ではrpmbuild -tb software-0.2.tar.gz(*.specが*.tar.gzの中に入っている)というのも一つの解ではあるな。あれは非常に楽だ。いい加減な*.specもあるからけっこう困るんだが。