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の配置

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 ハッシュ・バー）スイッチも付けます。パッケージをインストールする例を下記に示します。

                
$ 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）

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

ファイルの検証結果

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

rpm -U （アップグレード）

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

                
$ rpm -Uvh My*.rpm
Preparing...                ########################################### [100%]
   1:bMyPackageDep          ########################################### [ 50%]
   1:aMyPackageNew          ########################################### [100%]

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

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 whatprovides <filename>

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

上に戻る

RPMフロントエンド

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

上に戻る

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

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

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

上に戻る

ソースコード

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

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

上に戻る

Corewarsソースでの例

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

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

• http://download.sourceforge.net/corewars/corewars-0.9.13.tar.gz

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

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

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

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の管理機能を合体させることができるはずです。

参考文献

• WindowsからLinuxへのロードマップシリーズの他の記事も参考にしてください。（developerWorks 2003年11月）
  
  
• IBMdeveloperWorks のチュートリアルCompiling and installing software from sourcesではソースコードからのソフトウェア・パッケージを解凍、検証、設定、インストールする方法についてさらに深く説明しています。
  
  
• IBMdeveloperWorks の記事Compiling and installing software from sourcesでもLinuxでのソースコードのコンパイルやインストールについてさらに詳しく説明していますので、読んでみてください。
  
  
• 自分でパッケージを作る方法を、IBMdeveloperWorks の特集Debian Linuxパッケージを作成するとRPMによるソフトウェアのパッケージング: 第1回で説明していますので、読んでみてください。
  
  
• RPMやDebianのパッケージ管理によらない方法について、IBMdeveloperWorks の特集Stowを使ってのパッケージ管理で説明していますので、読んでみてください。
  
  
• セキュリティ面から、定期的にソフトウェアを更新することが重要です。自分のシステムを手早く容易に最新のものにするために、IBMdeveloperWorks のヒント、ソースからのアプリケーションのアップグレードを読んでみてください。
  
  
• IBMdeveloperWorks の特集にUnitedLinuxの紹介がありますので、読んでみてください。
  
  
• SourceForgeはオープンソース・プロジェクトにとって素晴らしい情報源です。読者のプロジェクトもここに置くことができます。
  
  
• Corewars projectはSourceForgeに山ほどあるプロジェクトの中の、単なる一つにすぎません。
  
  
• developerWorksOpen source zoneで、IBMでのオープンソース・プロジェクトを見ることができます。
  
  
• IBMのalphaWorksではWebサービスやGridツールボックスのように、IBMで生まれつつある技術を紹介しています。
  
  
• IBMでは単一ユーザーが低価格の年間ライセンス料でIBMの中心的ツール、ミドルウェアその他の技術が利用できる、developerWorks subscriptionを提供しています。
  
  
• IBMのSpeed-start your Linux app 2003では無料のLinuxソフトウェア評価キット（SEK）が入手できます。評価キットに含まれているのはDB2ユニバーサル・データベース、WebSphereアプリケーション・サーバー、WebSphereスタジオ、WebSphere MQ、Tivoliアクセス・マネージャ他盛りだくさんです！
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• RPM
• RPMを使う
• RPMフロントエンド
• Webminソフトウェア・パッケージ
• ソースコード
• Corewarsソースでの例
• ソースに神の恵みあれ！
• 参考文献
• 著者について
• コメント