RPMの10の問題
90年代のころは，インストールといえば，configure & make & make installが当り前でしたが，最近はパッケージシステムを使うのが当り前です．世の中のパッケージシステムの論争を見ていると，RPM vs Debian vs FreeBSD portsの三つ巴という状況が多いようです．だいたいどれも一長一短で，宗教論争に近いものがあります．
そこで，またもDebianとRPMが論争しているようです．RPMのメンテナが反論しているので，パッケージシステムの思想の一端がうかがえるかもしれません．
いつものごとく，超訳をしてみたので，感じをつかみたい方はどうぞ．(Jeffが，rpmのメンテナです)
- RPMのバックヤードで使われているBerkeley DBが遅い．Dpkgはplaintextでもっと早く同等のことをしている．(Claudio)
- Berkeley DBは十分に速い．plaintextの方がいい，ということは考えられない．(Jeff)
- パッケージのアップグレードするときに，前のバージョンの削除が必要となるのは，パッケージのスクリプトを複雑にする．(Claudio)
- 共有ライブラリを考慮すると，前のバージョンの削除は不可欠．(Jeff)
- ネットワーク機能がない(Claudio)
- rpmはネットワーククライアントの機能があるし，セキュリティの機能もある．(Jeff)
- rpmのマクロの拡張性が，あまりよくない．(Claudio)
- たいていのマクロ言語は，変ったところがある．そんなにおかしい?(Jeff)
- 仮想パッケージのために全ての代替パッケージを再生成しないといけない(Claudio)
- そんなことはない．仮想パッケージに適当なProvidesを書けば，Reqiuresを満すことができる．(Jeff)
- rpmのspecのchangelogのタイムスタンプのフォーマットが不完全(Claudio)
- たしかに悩ましい．解決しようとすると互換性が失われるので．(Jeff)
- ファイルの依存性が，一般的な仮想パッケージではなく，特殊な方法で扱われている．(Claudio)
- rpmは含まれる全ての依存性を同様に計算している．(Jeff)
- ディレクトリをシンボリックリンクで置き変えるような，単純な状況で問題がある．(Claudio)
- バージョン番号の比較が直感的でない．(Claudio)
- glibcのstrcmpを使っているだけなので，問題とは思っていない．(Jeff)
- インストール後の設定を対話的に決定することができない．(Claudio)
- それは，rpmのスコープ外．(Jeff)
もっとも，私がメインで使っているのはGentooなので，お気に入りのパッケージシステムは，Gentooのportageです．マイナーなので，こういう論争はあまり気にならなくてよいです．機能的には非常に柔軟性が高いのですが，遅いのが難点です．もっとも諦めているので，気になりませんが．
