次のページ 前のページ 目次へ

4. コンパイル済バイナリパッケージ

4.1 RPM の悪いところ

自分の手でパッケージをソースファイルから作ってインストールするのはおっ くうな作業だからといって、人気のある rpm 形式や deb 形式のパッケージや、新しい Stampede slp 形式の パッケージを利用する Linuxユーザがいます。 通常は rpm を使うと例の悪名高いオペレーティングシステムと同じくらい簡 単かつ速くパッケージをインストールできるのは確かでしょうが、勝手にイン ストールされるコンパイル済みのバイナリパッケージには間違いなく欠点もい くつかあります。

まず、ソフトウェアのパッケージは普通、"tarball" のソースファイルが最初 にリリースされ、コンパイル済みのバイナリパッケージはそれより数日、数週 間、場合によっては数ヵ月遅れてリリースされる点に注意してください。 最新の rpm パッケージでも、最新の "tarball" よりマイナー バージョンが 1 つか 2 つ遅れているのが普通です。 ですから、常に「最先端」のソフトウェアを追いかけ続けたいのであれば、 rpm や deb が出るのを待つのは得策ではないでしょう。 あまり人気のないパッケージについては、rpm 化されないこともあ るかもしれません。

2 番目に、"tarball" パッケージの方がより完全であり、オプションも多く、 カスタマイズしたりいじったりする余地も多くあります。バイナリ rpm 版で は、完全リリース版の一部の機能が消えていることもあります。 ソース rpm には完全なソースコードが入っているので、対応する "tarball" と同等です。したがって、rpm --recompile packagename.rpm か rpm --rebuild packagename.rpm のどちらかのオプションを使って 構築とインストールを行う必要があるでしょう。

2 番目に、コンパイル済みのパッケージの一部には正しくインストールできな いものがあります。あるいはインストールしたとしても、クラッシュしてコア を吐くかもしれません。これはシステムに入っているライブラリのバージョン の違いに依存するかもしれないし、rpm パッケージの用意がうまくできていな いのかもしれませんし、単にパッケージが壊れているのかもしれません。いず れの場合にせよ、rpm や deb をインストールする時には、 パッケージを作った人の技術を信じるしかありません。

最後に、ソースコードを持っていればいじったり、勉強する時の役に立ちます。 ソースコードはバイナリを作成した元々のアーカイブで持つ方が、それとは別 のソース rpm の形で持っているよりもずっと分かりやすいでしょう。

rpm パッケージのインストールは、必ずしもバカなわけではありま せん。もし、依存関係で競合があれば、rpm のインストールは失敗 するでしょう。同様に、現在のシステム上で動作しているライブラリと バージョンが違うライブラリを rpm が要求しているならば、 たとえ足りないライブラリの名前で既存のライブラリにシンボリックリンクを 張ってもインストールは実行されません。便利であるにもかかわらず、 rpm でのインストールは "tarball" のインストールと同じ理由で失 敗してしまいます。

書き込みに必要なパーミッションを得るためには、rpm や deb パッケージは root になってインストールする必要がありますが、 これは重大なセキュリティホールの可能性をもたらします。というのも、 うっかりとシステムのバイナリやライブラリを壊してしまうかもしれないし、 システムに大損害をもたらすトロイの木馬をインストールしてしま うことさえあるかもしれません。したがって、「信頼できる所」から rpm や deb のパッケージを入手するというのは重要なこ とです。いずれにせよ、インストールの前には rpm --checksig [パッケージ名].rpm を実行し、「(MD5 チェックサムに対する)署名の確認」をパッケージに対して 行うべきです。同様に強くお勧めするのは、 rpm -K --nopgp [パッケージ名].rpm の実行です。 deb パッケージでこれに対応するコマンドは dpkg -I | --info [パッケージ名].deb と dpkg -e | --control [パッケージ名].deb です。

本当に細かいことが気になる人のために(そして、こういった場合はよく 偏執病と言われます)、パッケージの個々の要素を展開してチェックするため の unrpm や rpmunpack というユーティリティがありま す。これは Sunsite のユーティリティ/パッケージ用ディレクトリ にあります。

Klee Diene は、インストール された .deb ファイルが改変されていないことを MD5 チェックサム で調べるための実験的な dpkgcert パッケージを作りました。この パッケージは Debian の ftp アーカイブから入手できます。現在のパッケージ名と バージョンは dpkgcert_0.2-4.1_all.deb です。 Jim Pick Software の サイトでは、Debian の通常のインストール対象となっているパッケージに対 して dpkgcert 証明書を提供するための実験的なサーバデータベース が動かされています。

最も単純な形では、rpm -i [ファイル名] や dpkg --install [ファイル名] コマンドでソフトウェア の展開とインストールが自動的に行われます。しかし注意してください。 これらのコマンドをむやみに使うと、システムが不安定になる恐れがあります!

ここで注意ですが、上記の警告は (被害の範囲こそ少ないものの) Slackware の インストールユーティリティである pkgtool にも当てはまります。 ソフトウェアの「自動的な」インストールはどんなものであっても注意が必要 です。

martian プログラムと alien プログラムを使うと、rpm, deb, Stampede の slp, tar.gz 形式の各ファイルを互いに変換できます。 これにより、これらのパッケージがどの Linux ディストリビューションでも 使えるようになります。

rpm コマンドや dpkg コマンドの man ページはじっくり 読んでください。また、詳しい情報については RPM HOWTO や TFUG の Quick Guide to Red Hat's Package Manager、 The Debian Package Management Tools を見てください。

4.2 RPM で起こる問題の例

Jan Hubicka は、 xaos というとっても良い感じのフラクタル表示パッケージを作って います。彼の ホームページ には、.tar.gz 形式と rpm 形式のパッケージが両方あり ます。ここは便利さをとって、"tarball" ではなく rpm 版を試しましょう。

残念なことに、xaos の rpm パッケージはインストールできません。 おかしな動作をするバージョンは 2 つあります。

rpm -i --test XaoS-3.0-1.i386.rpm 

error: failed dependencies:
        libslang.so.0 is needed by XaoS-3.0-1
        libpng.so.0 is needed by XaoS-3.0-1
        libaa.so.1 is needed by XaoS-3.0-1

rpm -i --test xaos-3.0-8.i386.rpm 

error: failed dependencies:
        libaa.so.1 is needed by xaos-3.0-8

ここでおかしいのは、libslang.so.0, libpng.so.0, libaa.so.1 は全部、テストを行ったマシンの /usr/lib にあることです。ライブラリのリリース番号は同じであっても、 xaos はちょっとバージョンが違うライブラリを使っているに違いあ りません。

テストとして、--nodeps オプションを使って xaos-3.0-8.i386.rpm を強制的にインストールし てみましょう。ところが、試しに xaos を実行してもクラッシュし てしまいます。 

xaos: error in loading shared libraries: xaos: undefined symbol: __fabsl

ここでくじけないで真相を追求してみましょう。xaos のバイナリ に対して ldd を実行してライブラリの依存関係を調べると、必要な 全ての共有ライブラリが表示されます。/usr/lib/libaa.so.1 ライブラリに対して nm を実行してシンボル参照を表示させると、 本当に __fabsl がないことが分かります。もちろん、足りない参照 が他のライブラリのどれかから抜けている可能性はあります…。 この問題、つまりライブラリの入れ換えにより足りないものが出てくることに ついては、対処の方法はありません。

でも大丈夫! "tarball" の XaoS-3.0.tar.gz を FTP サイト から入手しましょう。ホームページからも入手できます。これを構築してみま しょう。./configure, make を実行し、最後に(root になっ て) make install を実行すれば問題なくインストールできます。

これはパッケージ済みのバイナリで起こる、便利というよりも問題が先に立つ ようなたくさんの例のうちのひとつです。

次のページ 前のページ 目次へ