_ その昔、FIVA 10x をはじめとする Cyrix MediaGX を積んだマシンでは XFree86 3.3.x はまともに動かなかった。FreeBSD でも NetBSD でも Linux でも使いものにならなかったが、なぜか他の Linux とは違って RedHat だけはその現象が発生しないらしかった。RedHat 以外でもまともに使えるよう、たった数 kB のパッチを見るために数十 MB の巨大な SRPM (そのサイズのうちの 99% は自分がすでに持っている XFree86 のオリジナルソース)を ISDN 回線で何時間もかけてダウンロードした挙句にわかったのが、RedHat がバグを潰したのではなく、cyrix 用のドライバをまともに動いていた古いバージョンのものにそっくり差し替えただけだったという拍子抜けの事実。あれ以来、パッチやらコンパイルオプションやらを調べたいだけなのに、ソースの tar 玉をすでに持っていたとしても有無を言わさず同梱された巨大なバイナリ拾ってこなければならず、しかも RPM を使っていない OS ではその中身を調べるために展開するだけでもひと苦労な SRPM が大嫌いになった。
_ あれから何年もたち、なぜか今、RPM なパッケージを量産しております。
_ あのときは他人が作ったものの中身を調べるだけだったけど、これ、作る立場から見てもうんこじゃね？ .spec に書くパッケージ自身に関する定義部で Name: とか Version: とか Summary: とか指定しておいて、詳細説明だけはなぜか %description なんて別セクションに分離して書かなきゃならないとか、一般的な変数っつーか定数は %define var value で定義して %{var} で参照するけど、ソースファイルは Source1: で指定して %{SOURCE1} で参照して、かと思えば Patch1: で指定したファイルに対応するのは %{PATCH1} ではなく %patch1 でしかもこれはファイル名の参照ではなくいきなりパッチコマンドを実行しちゃうとか、ほかにもいちいち挙げていったらキリがないほど一貫性がなくてとにかくわかりにくい。せめて似たようなことをするのに Hoge: だったり %fuga だったり記法が違うのは何とかならんのか。
_ 開発途上のパッケージはいちいち SRPM/RPM に固めるより、.spec やソース、パッチがそれぞれバラバラになったままの方がリビジョン管理の都合上差分なんかをすぐに確認できてありがたいんだけど、SRPM は基本的には必要なときだけ展開してビルドして用が済んだら中身はすぐ消すという思想のようで、SRPM をバラした状態で管理することを考えてないというのもうっとーしい。作ってるパッケージが増えてきて、複数のパッケージで中身は違うけど同じ名前のファイル(Makefile とか config.h とか)を使いたくてもその名前でソースディレクトリに置いておけないんだもん。サブディレクトリ掘っても無視されるし。しかたないから別名で置いて .spec の中でリネームする処理を書くんだけど、そんなのはじめからパッケージ間で衝突が起きないようなしくみにしといてよ。いや、衝突するような使い方をするのが間違いなんだろうけどさ、じゃあどうやればいいの？
_ *BSD の ports/pkgsrc のほうがずっといいと言うつもりはさらさらないけどさ。あれはあれでうんこなところも多いし。RPM では root にならず平ユーザのまま他人所有のファイルやら他人に setuid されたファイルやらをパッケージの中にどんどん放りこめるなんてのは ports にはないメリットでうらやましいし( ports も平ユーザである程度はできるけど、バイナリパッケージを作るにはいったんインストールしなきゃならないので root 権限が必要)。でも、作る立場(≠使う立場)で見て RPM の方がすぐれてると思える点ってそれ以外にほとんど思いつかんのですが。