目次


Windows から Linux へのロードマップ

第 9 回 ソフトウェアのインストール

コンパイル済み RPM の使用とアプリケーションのコンパイル

Comments

コンテンツシリーズ

このコンテンツは全#シリーズのパート#です: Windows から Linux へのロードマップ

このシリーズの続きに乞うご期待。

このコンテンツはシリーズの一部分です:Windows から Linux へのロードマップ

このシリーズの続きに乞うご期待。

Linux をインストールする時に気がつくことの一つは、ディストリビューションに付属してくるパッケージが非常にたくさんあることでしょう。大部分のディストリビューションは Linux オペレーティング・システムと一緒にインストール用ツールと管理用ツールがついてきます。さらにインターネット・ツールがあり、開発ツールがあり、オフィス・ツールがあり、ゲームがあり、さらに聞いたこともないようなものまで付属してきます。Linux のディストリビューションでは何千ものパッケージが付属してくるのは珍しくありません。「install everything」を選ばなかった場合には、こうしたパッケージの一部のみがインストールされていることになります。

当然ながら疑問がわいてくるでしょう。「必要ないパッケージをどうやって削除するのか?」「インストールし損なったものをインストールするにはどうしたらよいのか?」「ディストリビューション付属のソフトウェアと別のソフトウェアは使えるのか?」

RPM

Linux がインストールされると、そこにインストールされている RPM に関する情報がたくさんあるのに気がつくでしょう。RPM は Redhat Package Manager を表し、Redhat が無償提供したものですが、現在では Redhat や UnitedLinux ほか多くのディストリビューションの管理ソフトウェアとして標準になっているものです。

RPM は基本的に、ある特定のマシンのアーキテクチャ上にインストールして実行可能な、Linux 用ソフトウェアを含んだパッケージです。例えば「第 3 回 Webmin 入門」では RPM から webmin パッケージをインストールしました。選択したディストリビューションに最初にロードされていたソフトウェアはすべて RPM からインストールされたものです。

RPM の解析

RPM はファイルをパッケージしたものです。RPM には .spec ファイルが含まれていますが、このファイルにはパッケージの機能や依存関係 (RPM を実行する前にどんなパッケージが入っている必要があるか) など、パッケージに関する情報が含まれています。また.spec にはファイルをシステムのどこにロードすべきか、初期パーミッションは何かといった説明のある、マニフェストも入っています。RPM には RPM パッケージの開発者が書いたプリインストール用のスクリプトも入っていますし、コンパイルしたバイナリ・ファイル、ポストインストール用のスクリプトもあります。

RPM の配置

.spec
プリインストール・スクリプト
バイナリ・ファイル
バイナリ・ファイル
...
バイナリ・ファイル
ポストインストール・スクリプト

RPM がインストールされる時には、システムは最初にパッケージの依存関係が満足されているかどうかをチェックします。満足されていない場合は、強制インストールのオプションを選択していない限り、インストールは中止されます。

依存関係がすべてクリアされていれば、プリインストール・スクリプトが実行されます。このスクリプトは何でもすることができます。普通はユーザーとディレクトリを生成しますが、各種の動的設定も行うことができ、実行中のシステムでソースコードをカスタム・コンパイルすることまでできます。

プリインストール・スクリプトが問題なく終了すれば、マニフェストに従ってバイナリ・ファイルがシステムにコピーされます。すべてのファイルがコピーされてパーミッションが設定されると、ポストインストール・スクリプトが実行されます。このスクリプトも、ほとんど何でもすることができます。

これがすべて終了すると、パッケージに関する情報が RPM データベースに追加され、インストールが完了します。この単純なシステムで、ずっと高級な商用インストーラーで行うのと全く同じことができるのです。

RPM データベース

RPM データベースのおかげで RPM がスマートになっています。このデータベースは普通 /var/lib/rpm ディレクトリにあり、システムにインストールされているすべての RPM に関する情報を持っています。このデータベースはパッケージ間の依存関係を理解しており、あるパッケージを削除すると他のパッケージが動作しなくなるような場合には、その削除に対して警告を発します。また、あるパッケージでインストールされたすべてのファイルとその初期状態も理解しています。さらに各パッケージのドキュメンテーションと設定ファイルの場所も分かっています。これは大量の情報のようですが、実際大量の情報なのです。だからといって容量が巨大なわけではありません。1,066 のパッケージで 203,272 のファイルでもデータベースのファイルは 45MB しかありません。RPM はパッケージをロードしたりアンロードしたりする時には、このデータベースを使って依存関係をチェックします。ユーザーがこのデータベースに対して問い合わせ (クエリー) することもできます。

RPM を使う

RPM パッケージを操作するプログラムには rpm という、うまい名前が付いています。 rpm はいくつかのモードで実行されますが、一番普通の使い方はインストール、アップグレード、クエリー、検証、それに削除でしょう。

rpm -i (インストール)

あるパッケージを最初にインストールする時には、-i つまりインストール・モードを使います。単純に rpm でバイナリ・パッケージを指定して実行すると rpm がシステムにインストールされます。インストールは通常何秒かかかります。私はパッケージをインストールする時には -v (verbose 冗長) スイッチを付けてインストール・プロセスの情報がより多く得られるようにし、またパッケージがインストールされるに従ってハッシュ記号 (#) がプログレス・バーとしてコンソールに表示されるように、-h (hash bar ハッシュ・バー) スイッチも付けます。パッケージをインストールする例を下記に示します。

リスト 1. MyPackage をインストールする
$ rpm -ivh MyPackage-1.0.0.i386.rpm
Preparing...                ########################################### [100%]
   1:MyPackage              ########################################### [100%]

これだけです!これで MyPackage はインストールされ、いつでも使用可能です。

rpm -e (削除)

インストールされているパッケージを削除するには -e スイッチを使います。 rpm はデータベースを使って、そのパッケージが持っていたすべてのファイルを削除します。削除しようとしているパッケージが他のパッケージの起動条件になっている場合には rpm は中止されます。削除を強行するには nodeps スイッチを使います。 ( nodeps はインストールを強行する場合にも使います) 。このスイッチを使う時には充分 注意してください。他のパッケージの起動条件となっているパッケージを削除すると予期せぬ結果になりかねません。上でインストールしたパッケージを削除するコマンドを次に示します。

$ rpm -e MyPackage

削除の際にはパッケージの詳細バージョンまで指定する必要はありません。インストールの時はファイル名まで指定していたので完全な名前が必要でしたが、インストールされているパッケージはパッケージ名だけで参照できます。バージョン番号まで含め、パッケージ名がすべてです。

rpm -V (検証 verify)

検証のスイッチは非常に使い道があります。パッケージに含まれるファイルに対して、インストールした時の状態と現在の状態を比較できるのです。その差は次のようなコードを使って表現されます。

ファイルの検証結果

  • S: ファイルサイズが異なる
  • M: モードが異なる (パーミッションとファイルタイプを含む)
  • 5: MD5 チェックサムが異なる
  • D: デバイスのメジャー/マイナー番号が不一致
  • L: rreadLink(2)のパスが不一致
  • U: ユーザー所有権が異なる
  • G: グループ所有権が異なる
  • T: mTime が異なる

あるパッケージに対して rpm -V を実行しようとして実行ファイルのサイズが変わっているのに気が付いたら、セキュリティ侵害が起きた可能性があります。

rpm -U (アップグレード)

あるパッケージが一旦インストールされると、同じ名前のパッケージをインストールしようとしても、既にインストールされていますというメッセージが表示されるだけです。パッケージを新しいバージョンにアップグレードしたい時には -U スイッチを使います。アップグレードには別の効果もあります。アップグレードを複数のパッケージ名に対して実行すると、パッケージを依存関係の順に置いていくのです。つまり必要なパッケージが最初にインストールされるのです。アップグレード・スイッチはパッケージが既にインストールされているかどうかのチェックにも使えるので、 -i スイッチを使ってインストールする代わりにアップグレード・スイッチを使う人もいます。アップグレード・スイッチを使って rpm パッケージをいくつかロードする方一例を次に示します。

リスト 2. 対話型アップグレード
$ rpm -Uvh My*.rpm
Preparing...                ########################################### [100%]
   1:bMyPackageDep          ########################################### [ 50%]
   1:aMyPackageNew          ########################################### [100%]

上の例では aMyPackageNew のインストールに bMyPackageDep が必要条件なので、ファイル名の順は逆になっていますが、 rpm はこの 2 つを正しく並べ替えているのです。

rpm -q (クエリー)

rpm データベースにクエリーして有用な情報を取り出すことができます。rpm データベースへのリードアクセスユーザーであれば誰でもクエリーを実行できます。デフォルトではリードアクセスユーザーです。クエリーを実行するには、クエリーしたいパッケージ名と共に -q スイッチを使います。これでパッケージのバージョンが返ってきます。

$ rpm -q MyPackage
MyPackage-1.0.0

パッケージ名は完全に正確でなければなりません。ワイルドカードは使えません。パッケージの完全な名前を覚えていない場合は grep ツールを使って見つけることができます。インストールされたすべてのパッケージを -qa スイッチでクエリーし、覚えているテキスト部分と grep でその情報をパイプします。例えば、

$ rpm -qa | grep IBM
IBMWSAppDev-Product-5.0-0
IBMWSSiteDevExp-Core-5.0-0
IBMWSSiteDev-Core-5.0-0
IBMWSTools-WAS-BASE-V5-5.0-0
IBMJava118-SDK-1.1.8-5.0
IBMWSWB-samples-5.0-0
IBMWSWB-5.0-0
IBMWSAppDev-Core-5.0-0
IBMWSAppDev-5.0-0
IBMWSTools-5.0-0

バージョン番号以外にも rpm -q でパッケージに関する有用な情報が得られます。一例を次に挙げます。

rpm クエリーで情報を取得する

  • rpm -q changelog: パッケージの開発変更履歴を表示する
  • rpm -qc: パッケージの設定ファイルを表示する
  • rpm -qd: パッケージのドキュメンテーション・ファイルを表示する
  • rpm -qi: パッケージについての説明を表示する
  • rpm -ql: パッケージのファイルを表示する
  • rpm -qR: パッケージの依存関係を表示する

クエリーには (パッケージではなく) ファイルに対して実行される面白いコマンドもあります。

rpm -q whatprovides <filename>

上のコマンドは、与えられたファイル名に関連付けられたパッケージを特定します。情報は絶対パスを含めて rpm データベースに保存されているので、ファイル名も絶対パスを含んでいる必要があります。

RPM フロントエンド

コンソールから rpm を操作するのは簡単ですが、グラフィカルなインターフェースで操作する方がより便利です。Linux では普通、rpm プログラムとインターフェースするフロントエンド・プログラムがあります。各ディストリビューションにはフロントエンドがありますが、それぞれ異なっています。付属のパッケージ管理ツールに関する情報については、ディストリビューションのドキュメンテーションを参考にしてください。

Webmin ソフトウェア・パッケージ

Webmin にも RPM パッケージを操作するための簡単な Web ベースのフロントエンドがあります。

図 1. Webmin RPM インターフェース

ソフトウェアはここから簡単にインストール、削除、クエリーができます。また URL から直接インストールすることもできます。 apt や Redhat Network のような rpm エンハンスメント・ツールをインストールしてあれば Webmin はそうしたサイトを選び出し、サイトとのインターフェースをします。

ソースコード

Linux はオープンソースのオペレーティング・システムなので、ソフトウェアのコンパイルに必要な開発ツールが一式付いてきます。ほとんどのパッケージはバイナリの RPM として提供されていますが、こうしたパッケージしか使えないわけではありません。その気になれば、生のソースコードをダウンロードして自分のシステム用にカスタム・コンパイルすることもできます。

ただしソースからコンパイルしたものを実使用のシステムに使うと問題を起こしたり、購入した商用ソフトウェア (例えば IBM DB2 など) に対するサポートを受けられなくなったりする場合もあるので注意が必要です。その代わりソースからコンパイルするのに慣れておくと、ソフトウェアにパッチをあてたり、他の環境から移植されたパッケージを操作したりできるようになります。コードをうまくコンパイルできれば独自の RPM を作ることもできるのです!

Corewars ソースでの例

ソースからコンパイルするのがどれほど簡単かを示すために、Corewars と呼ぶシミュレーション・ゲーム (リンクは参考文献) をコンパイルしてみましょう。その Web サイトによると、「Corewars とはシミュレーション・ゲームで、ある仮想的なコンピューターで何人かの戦士がお互いに撃破し合うものです。戦士を記述するにはアセンブラーに似た 2 つの言語、Corewars と Redcode のどちらかを使います。Corewars はデフォルトで、学ぶのも理解するのも簡単です。Redcode はより高度で強力な命令を持っていますが、Corewars よりも学ぶのに時間がかかります。」

最初のステップは、ソースコードのパッケージを Web サイトからダウンロードすることです。

コードをダウンロードしたら解凍します。

tar -xvzf corewars-0.9.13.tar.gz

このファイルは解凍されてカレント・ディレクトリに入ります。標準的なやり方としては、製品名と同じ名前のディレクトリにソースコードを入れます。この場合では corewars-0.9.13 というディレクトリです。

そのディレクトリに入るとソースコードとドキュメンテーション、設定スクリプトそれに README があります。大部分のパッケージには INSTALL というファイルと README というファイルが付いてきますので、コンパイルをする前にこうした資料を読んでおいてください。こうした資料を読んでおくことで問題を未然に防ぐことができて無駄に苦しまずにすみますし、正しいコンパイル方法やインストール方法も分かります。私がソースからコンパイルする際に経験した問題の大部分は、実は単に正しい手順に従わなかったことに起因しているのです。

次のステップとして一番普通なのは configure スクリプトを実行することです。 configure は Autoconf パッケージの一部で、お手持ちの Linux ディストリビューションの開発ツールに含まれているものです。Autoconf のパッケージの説明によると「GNU の Autoconf はソースコードや Makefiles を設定するためのツールです。設定オプションを多様に指定できるので、Autoconf を使って可搬性のある設定変更可能なパッケージを作ることができます。」

configure スクリプトはシステムに対して一連のテストを実行し、そのディストリビューションとアーキテクチャに最適なコンパイル方法を決定します。次にそのシステム用にカスタム化した Makefile を生成します。そのシステムでコンパイルするのに問題がある場合には configure が知らせます。 configure は通常、そのパッケージが正しくコンパイルされるようにフィーチャーをカスタマイズしてコンパイルに入れ込んだり、ライブラリや必要なファイルの場所を示すパラメーターを追加したりできるようになっています。

./configure

いくつかのテストが実行され、成功で終わります。次に下記を使ってプログラムをビルドします。

make

コンパイルにエラーがある場合は、問題を特定して修正しなければなりません。これは簡単ではなく、自分の環境とプログラミング全般に関するかなりの知識が必要になります。すべてがうまく行ったら下記でソフトウェアをインストールします。

make install

ファイルが正しい場所にコピーされ、ファイルパーミッションが更新され、設定ファイルがコピーされ、ドキュメンテーションがマニュアル・ページに追加されます。

ではプログラムを実行して結果を見てみましょう。グラフィカルなプログラムなので、プログラムを起動する時には X を実行しておく必要があります。上で行った make install は、このプログラムを実行パスに置いたはずです。

corewars

苦労が報われ、グラフィカルなスクリーンが眼前に現れるはずです。

図 2. 成功!

corewars のルールはこの記事の範囲外ですが、この面白いシミュレーション・ゲームに関するドキュメンテーションは man ページに説明されています( man corewars )。

corewars のコンパイルは典型的なものでしたが、いろいろな変形も可能です。 configure スクリプトのスイッチを使ってコンパイルすることでプログラムのフィーチャーを調整したり、Makefile の別コマンドを使ってコンパイルの方法を調整したりすること等もできます。

このプログラムは rpm を使ってインストールされたものではないので、rpm データベースにはエントリーがありません。インストールしたプログラムがうまく動かない場合に備えて、たいていの Makefiles にはソフトウェアを削除するためのアンインストールのパラメーターもあります。

make uninstall

生のソースコードを操作しても RPM データベースには何も反映されないことには注意してください。つまりこの方法でインストールされたソフトウェアは管理されていないので、十分に注意して作業してください。

ソース RPM

RPM が生成されると、ソース RPM と呼ばれるものもできます。これは複数のアーキテクチャ上でビルドされるように設計された、ソースコードと組み合わせの SPEC ファイルです。これは良いとこ取りなのです。つまり、ソース RPM で自分のシステム用にソフトウェアをカスタム・コンパイルできますが、出来上がったものは生のバイナリではなく、インストールできる RPM なのです。コンパイル済みの RPM として入手できるパッケージの大部分は、SRPM としても入手できます。この方法を使って、Linux のいろいろなプラットフォームでソフトウェアを手軽に交換することもできます。異なるプラットフォームでコンパイルがうまくいったらば、出来上がったその RPM を他の人に使ってもらうことも考えてみてください。

ソースに神の恵みあれ!

Linux が初めての人にとっては、ソフトウェアのインストール手法は今まで慣れたものとはちょっと違って戸惑うかもしれません。でも RPM によるインストール手法はスマートかつ強力で、読者もすぐに好きになるでしょう。

コンソールから rpms を操作する上での各種のオプションに慣れる必要もありますが、日々の操作には簡単に扱えるフロントエンドのインターフェースもあります。ディストリビューションにも付属してくるはずですし、Webmin のようなものもあります。

そこで使えるのはコンパイル済みの rpms だけではありません。オープンソースという Linux の特長を生かして、ソースコードから直接アプリケーションをコンパイルすることもできるのです。熟練した人であればコンパイルも普通、簡単なものです。ただし、ソースコードからインストールされたコードは rpm データベースにエントリーが無いことはよく覚えておいてください。またソースを扱う時にはソース rpms を使うことも検討してください。コンパイルしたソースの強力さと rpms の管理機能を合体させることができるはずです。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Linux
ArticleID=230454
ArticleTitle=Windows から Linux へのロードマップ: 第 9 回 ソフトウェアのインストール
publish-date=11112003