|
次のページ
前のページ
目次へ
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 というとっても良い感じのフラクタル表示パッケージを作って
います。彼の
ホームページ
には、 残念なことに、xaos の rpm パッケージはインストールできません。 おかしな動作をするバージョンは 2 つあります。 rpm -i --test XaoS-3.0-1.i386.rpm
rpm -i --test xaos-3.0-8.i386.rpm
ここでおかしいのは、 テストとして、--nodeps オプションを使って
ここでくじけないで真相を追求してみましょう。xaos のバイナリ
に対して ldd を実行してライブラリの依存関係を調べると、必要な
全ての共有ライブラリが表示されます。 でも大丈夫! "tarball" の これはパッケージ済みのバイナリで起こる、便利というよりも問題が先に立つ ようなたくさんの例のうちのひとつです。 次のページ 前のページ 目次へ |
[ |