エンタープライズ:特集 2003/09/26 18:00:00 更新


特集:第2回 RPM活用のステップアップ−SRPMリビルドとコンパイルマスター (1/6)

Linuxでバイナリパッケージを使わない人の多くは、チューニングをしたいから、最新リリースがすぐに適用できないからという理由が多い。SRPMを使いこなせば、前者の問題は解決可能だ。

 Linuxで標準的なパッケージ「RPM」(Red Hat Package Manager)は、Windowsのように容易にインストール、アンインストールなどが行えることを第1回目で解説した。基本的な事項は連載「リファレンスRPM」の第1回を読んでいただくとして、今回はもうひとつのパッケージ「SRPM」(ファイル形式、src.rpm)の使い方について解説していこう。

 第1回目でも触れたように、拡張子rpmのファイルはソフトウェアのインストール、アンインストール、アップデートなどを目的にパッケージされたものだ。このため、自分好みの機能を加えたり、必要のない機能を削るなどのチューニング目的に適さない。しかし、サーバとして利用するLinuxでは、パフォーマンス重視のために必要メモリ量を極限に削るなどのカスタマイズを行うことがある。このような用途には、あらかじめ標準的な機能を盛り込んでコンパイル済みのrpmでは不都合になる。

 SRPMを利用すれば、このようなチューニングの要望にも応えられることが可能だ。また、実際に「ソースファイルをコンパイルする」というプロセスも見られるため、RPMに慣れ親しんでいる人でもsrc.rpmに触れることでtarボールからのソースコンパイルを理解する手助けになるだろう。

パッケージのリビルドは何のために行う

 かつてのLinuxやUNIXは、伝統的にバイナリファイルを実際に動作させる環境上でソースファイルからコンパイルした。ソースファイルさえあれば、あとはソフトウェアが動くまでの条件としてプラットフォームごとのコンパイラやライブラリがあれば、実行ファイルが生成できたのだ。環境に合わないソースコード内容であれば、利用者自らが修正することもできる。コンパイル以前の、ソースファイルが配布されれば、プラットフォームの垣根を越えて、幅広い互換性を保つことができた。

 しかし、時は変わりLinuxにも運用の手軽さが要求されてきた。また、商用にてサービス重視の運用を行う上では、複雑な操作が不安定さにつながってしまうこともあり得る。このような背景に対する回答の1つがバイナリ(パッケージ)配布の1つ、RPMなのだ。

 しかし、この万能とも思えたRPMであっても、RPMをサポートするLinuxディストリビューションごとに方言ができてしまった(ディレクトリ構成違いなど)。さらに同じRed Hat Linuxであっても7.3〜9それぞれに別のRPMファイルが用意されている。ターゲットとなる環境、カーネルバージョンや標準ライブラリのバージョンがそれぞれ異なるためだ。このため、世間一般の広い目で見れば、RPMで厳密に管理していくためには、多くのディストリビューションごと、さらにそのバージョンごとにバイナリパッケージを用意しなければならない。現実は、他のバージョン向け、他のディストリビューション向けのバイナリパッケージでもインストールでき、動作する可能性はある。それでも、そのパッケージは動作環境に最適化されたものではないことを念頭に置かなくてはならない。

 こうした状況にはsrc.rpmからのリビルドで対応することがベストとされている。src.rpmは実質的にはtar.gzのソース(アーカイブファイル)と同じだが、RPMパッケージに必要な情報ファイルが用意されており、最適化されたコンパイルが行えるようにしてある。これにより、src.rpmからリビルドしたパッケージであれば、環境に最適化されており、安心して使うことができるのだ。tarボールからのコンパイルと比べ、うまくコンパイルできる可能性が高い。

どのような時にSRPMが役立つのか

 RPMによってソフトウェアのアップデートなどが容易になることが、現在多くの利用者の目的だ。通常のRPMパッケージを利用していて何の不都合もなければ、あえてSRPMを利用することはない。それではどのようなケースが具体的にあるのか、挙げてみよう。

 ひとつはライブラリの入れ替えで実行時にエラーが発生する場合。Windowsでいえば「VisualBasicのランタイムライブラリが存在しない」などというエラー状況に相当する。

 もうひとつは、プログラム本来の機能がコンパイル時に無効化されている場合だ。メールクライアントであれば、SASLやKerberosなどの暗号化プロトコルが無効になっていたり、PHPのmbstringsがオフになっていたりすることがある。暗号化プロトコルやSQLなどデータベースなどを利用するような機能はリンクするライブラリが増え、コンパイル後のプログラムサイズが大きくなる。パッケージャの判断に委ねらる部分で一概にはいえないが、あまり使われない機能だと判断されると、標準で無効化されることはよくあるのだ。

 プログラムによってはコンパイル後でもモジュールを使って組み込めるものもある。例えば最近のカーネル機能のほとんどはモジュール化されており「カーネルの再構築」は必須の作業ではなくなってきている。しかし、モジュール化されていない(あるいはできない)機能もまだ多く、それらはコンパイル時の設定で有効にし、リビルドしなければならない。

 機能を有効/無効にするといった情報はSPECファイルに記述されているので、プログラムの機能を変更は少し手を加える必要がある。しかし、ライブラリやバージョンの問題が発生するというだけであれば、src.rpmからそのまま新しいバイナリパッケージを作ればよい。それならば、1つのコマンドで処理することができる。

      | 1 2 3 4 5 6 | 次のページ

[渡辺裕一,ITmedia]