再生への道を歩み始めたRPM開発

RPMパッケージ・マネージャー(RPM)のパッケージ形式とユーティリティーはRed Hat Enterprise Linux(RHEL)、Fedora Core、SUSE、Mandrivaにとって屋台骨のようなものであり、それはその他多くの小さなLinuxディストリビューターやLinux Standard Baseにとっても同じだ。そのRPMのユーティリティーと仕様は最近までRed Hatが保守していたが、2006年に同社がrpm.orgを開発拠点として再編しRPMの開発を切り離して以来、不安定な時期が続いていた。

Red Hat時代のほとんどの期間、RPM(当初はRed Hat Package Managerを意味していた)の保守に当たっていたのはJeff Johnsonだった。しかし、Johnsonは2005年半ばに同社を去る。そのとき、RPMのバージョンは4.4.2だった。

Johnsonは退職後も独自に開発を続け、wraptastic.orgでRPMを配布してきた。2007年1月現在、JohnsonのRPMは4.4.6にアップデートされ、多くのバグ修正や「推奨」「提案」依存性などの重要な機能強化が施されている。

しかし、Linuxのディストリビューターは、今も旧版のRPM 4.4.2を同梱している。その一因はRed HatとJohnsonの間に残る不和だが、自らが必要とするRPMパッケージの積極的な維持にディストリビューター自身が実質的に参加してこなかったことも大きい。Johnsonの退社後、Red Hatでは、Paul Nasratがパッチ・メンテナンスを担当したが、対象は4.4.2に限られていた。

JohnsonのRPMは更新される一方、ディストリビューターはすでに古くなった4.4.2を使い続けている。したがって、ときと共に互換性の喪失が明瞭になってくるだろうが、むしろその方がよいかもしれない。分裂が明確になれば、商用ディストリビューターも、自らが必要とするRPMの積極的な開発に乗り出すだろう――サポート契約を考えれば、基盤を構成する重要部分を衰退に任せるなど論外だろうから。

一方、Fedora Advisory Boardは、この問題について2006年8月にメーリングリスト上で論じ、RPMを使用する他のディストリビューターに意見を求めることを決定した。そして、同年12月、討論の結果――コミュニティー主導でRPMを開発することとrpm.org Webサイトを改組して拠点とすること――を発表した。新しいrpm.orgには、ソースコード・リポジトリー、wiki、メーリングリストが置かれる。

Red Hatも、Max Spevack名で声明を発表し、再び専従者一人体制でRPMの開発に当たることを明らかにする一方、RPMを利用しているすべてのディストリビューターやそれ以外の団体に対してプログラミング・試用・文書作成での参加を呼びかけた。

新生rpm.orgの第一の目標は、RPM 4.4.2コードを技術的に評価・整理し、RPMを利用するディストリビューターのすべてが共有する新しいRPMを確立することだ。その後、バグ修正手続きを軌道に乗せ、RPMとPythonのバインディングを改良することまで決まっている。

今回の取り組みがいつ実を結ぶかは定かではない。Spevackによれば、新しいrpm.orgメーリングリストへの投稿は12月は多かったが、1月に落ち込み、2月になって再び増えている。さまざまなディストリビューターからもたらされるバグの修正とパッチをまとめるという退屈な仕事も確実に動き始め、今後のパッケージング・ユーティリティーに関する議論も始まっている。

メーリングリストへの2月の投稿を見ると、Red Hat以外からの寄与が増えており、SUSEやPLDだけでなく、Wind Riverさえ、RPM-maintメーリングリストの議論に参加している。こうしたディストリビューターは今まで相互協力をせずずっと単独でRPMを保守していたことを考えると、吉兆と言うべきだろう。たとえ新生rpm.orgの離陸に長い時間がかかったとしても、今回の動きは、Red HatがRPMパッケージ管理システムの開発における協調の必要性に気づいたことを示し、それは、Red Hatの顧客やサードパーティーの利用者にとって歓迎すべきことだ。

NewsForge.com 原文