Skip to content

翻訳記事：

  • RED HAT Magazineは、米国発の記事を翻訳したものです。

RED HAT SPEAKS

RPMで快適Linux環境（Part 1）

執筆者：Chip Turner

  • はじめに
  • クエリ
  • パッケージのインストールと削除
  • yum、up2date、およびredhat-config-packages
  • 結論
  • 執筆者について

はじめに

Linuxは個人の遊び道具から業務レベルのコンピューティングプラットフォームへと成長を遂げ、それに伴うさまざまな漸次的および革命的な変化によって、従来のUNIX環境は大幅に改善されました。そうした環境改善の1つにソフトウェアパッケージングの発展があり、初期の単純なtarアーカイブから出発して現在のはるかに高度な最新のRPMが実現されています。RPMについて誰に尋ねても、その答えにはパッケージングについて、そしてRed Hatについてのコメントが含まれるのではないでしょうか。RPMはもともとRed HatによってRed Hat Linuxオペレーティングシステム用に作成されましたが、強力な機能を備えていたため、他の多くのLinuxディストリビューションで採用され、市販のLinuxディストリビューションの大部分で採用されています。

RPM（RPM Package Managerの再帰的頭字語）は、パッケージ（アプリケーション、データ、その他のファイルが含まれた圧縮ファイルで、tarballまたはzipファイルのようなもの）、データベース（特定のシステムにインストールされているパッケージのリスト）、およびコンパイルレシピ（これによって、多数のファイルが他のシステムへのインストールに適したパッケージに変換される）の3つの主要な機能領域で構成されています。この記事では、主に最初の2つ（パッケージの操作とユーザシステム上のデータベース）について説明します。

注意: この記事では、「RPM」とはRPM全体を指し、「rpm」はRPMとの対話のほとんどに使用するコマンドラインユーティリティを指します。

単純なtarballと実際のRPMにはいくつかの違いがありますが、最も重要な違いの1つはバージョニン分けということについてのコンセプトです。あらゆるRPMには、特定のバージョン（:version RPMがパッケージングしているソフトウェアのバージョンを示し、通常、RPMのベースになっているオープンソースプロジェクトと同じ）、リリース（:release 特定バージョンのソフトウェアのPRMパッケージングのバージョンと考えることができる）、およびepoch（:epoch 通常は隠蔽され、表面上は使用に影響しない「マジック」）があります。RPMと単純なtarballとのもう1つのきわめて重要な相違は、依存性です。依存性とは基本的に、正しく動作するために他のソフトウェアが必要であることを示すパッケージのステートメントです。ここで、他のソフトウェアとはファイル、共有ライブラリ、または別のパッケージの名前の場合もあります。デフォルトの動作モードでは、パッケージのすべての依存性が満たされないと、RPMはそのパッケージのインストールを認めません。

標準的なFedora Core 1のインストールでは、700�1,200のパッケージがあります。これらの各パッケージには、ユーザのシステム上で数百または数千のファイルが含まれます。実際には、ファイルシステム上のあらゆるファイルはほとんど例外なくRPMによってインストールされます（もちろん、ユーザ自身が手動で配置するファイル以外、という意味です）。

RPMについて詳しく探るには、まずあなたがインストールしたソフトウェアのRPMデータベースから始めましょう。最も基本的なクエリは、パッケージがインストールされているかどうかを判定することです。たとえば、xgalagaというゲームがインストールされているかどうか確認するとします。rpm -q xgalagaコマンドを入力すると、rpmはインストールされているそのパッケージのバージョンをレポートするか、または（こちらの可能性の方が高いですが）そのパッケージは存在しないとレポートします。さらに、簡単なコマンドラインによってデータベースを検索し、ファイル/bin/shの元になっているパッケージを確認できます。これには、シェルプロンプトでrpm -q -f /bin/shコマンドを入力します。rpmは/bin/shの元になっているパッケージの名前、バージョン、およびリリースを返します。Fedora Core（および既知のあらゆるLinuxディストリビューション）では、これはbashパッケージに含まれます。

ところで、bashとはどんなものでしょうか。幸いなことに、RPMデータベースではbashの詳細についても知ることができます。bashについて確認するには、rpm -q -i bashと入力します。例1「rpm -q -i bashの出力」はその出力を示しています。表示されるデータのうち、Descriptionセクションの文章から、bashがBourne Again Shellであることがわかります。 

Name        : bash                         Relocations: /usr
Version     : 2.05b                             Vendor: Red Hat, Inc.
Release     : 34                            Build Date: Tue 09 Dec 2003 01:07:19 PM EST
Install Date: Tue 23 Mar 2004 10:24:45 PM EST      Build Host: thor.perf.redhat.com
Group       : System Environment/Shells     Source RPM: bash-2.05b-34.src.rpm
Size        : 4519964                          License: GPL
Signature   : DSA/SHA1, Tue 23 Dec 2003 10:30:11 AM EST, Key ID b44269d04f2a6fd2
Packager    : Red Hat, Inc. 
Summary     : The GNU Bourne Again shell (bash).
Description :
The GNU project Bourne Again shell (bash) is a shell or command
language interpreter that is compatible with the Bourne shell
(sh). Bash incorporates useful features from the Korn shell (ksh) and
the C shell (csh) and most sh scripts can be run by bash without
modification. Bash is the default shell for Red Hat Linux.
例1. rpm -q -i bashの出力

この簡単な例から、2つの重要なことがわかります。第1に、RPMとの（ほとんど）すべての対話はコマンドラインユーティリティのrpmを通じて行われるということです。第2に、RPMにはインストール済みのあらゆるパッケージに関する相当な情報が保持されているということです。次に、RPMで（パッケージ自体、およびインストール済みパッケージのデータベースの両方に）記録されている情報について説明します。

クエリ

rpmユーティリティを使用して情報を発見することを、一般にクエリといいます。rpm内部の各種の機能にアクセスするには単一のコマンドを使用しますが、rpmには複数のモードがあります。コマンドラインでrpmのあとに続ける最初のパラメータは、通常、モードの選択です。前述のいくつかの例では、そのパラメータは-qであり、これはrpmのクエリモードをアクティブにするように指示するものです。そのあとに指定したパラメータの-iと-fは、クエリモードのサブモードで、-iはインストールされているパッケージに関する情報、-fはファイルの元になっているパッケージの情報を指示しています。

通常、コマンドラインではモードとサブモードのパラメータは1つに連結されます。そこで、前述の例では、それぞれ簡単にrpm -qf /bin/shおよびrpm -qi bashを使用できます。RPMの世界では、この形式のコマンド呼び出しが一般的になっているので、以下の例ではこの形式を使用します。

rpmでは、-iや-fのほかに、インストールされているパッケージ内のファイルを一覧することもできます。setupというパッケージに含まれているファイルを確認するには、rpm -ql setupと入力します。これにより、そのパッケージに含まれるファイルのリストが生成されます。それらのファイルの詳細をls -lと類似した形式で取得するには、-v（冗長）サブモードを追加します。この場合、コマンドはrpm -ql -v setupになりますが、実際には-vを-qlと結合し、-qlvと簡略化できます。

通常のシステムには数百のパッケージがインストールされていますが、RPMデータベースに対してクエリを実行し、インストールされているパッケージの完全な一覧を取得することが必要な場合もあります。この場合、クエリモードは-aサブモードで、コマンドはrpm -qaです。この出力は相当なデータ量になることが多いので、通常、grepを使用してフィルタをかけます。たとえばrpm -qa | grep ^perlでは、名前がperlで始まるパッケージがすべてリストされます。さらに、このコマンドを使用して、システム上にインストールされているパッケージのスナップショットを作成し、それを保存しておけば、あとで比較する（または、別のマシンのパッケージと比較する）こともできます。より複雑な使用例を例2「段階の異なるRPMデータベースの比較」で示しています。この例では、一覧を保存し、diffユーティリティを使用してパッケージの削除や追加を検出する方法が示されています。実は、大部分のシステムには、インストールされているパッケージリストの変化を記録し、その出力を/var/log/rpmpkgs（古いバージョンのファイルはrpmpkgs.1、rpmpkgs.2、などとなる）に保存するcronジョブがあります。このファイルの作成の詳細については、/etc/cron.daily/rpmを参照してください。 

# rpm -qa | sort > /tmp/before.lst
# rpm -e wget
# rpm -qa | sort > /tmp/after.lst
# diff -u /tmp/before.lst /tmp/after.lst
--- /tmp/before.lst     2004-03-24 09:55:58.000000000 -0500
+++ /tmp/after.lst      2004-03-24 09:56:10.000000000 -0500
@@ -712,7 +712,6 @@
 vte-0.11.10-4
 w3c-libwww-5.4.0-7
 webalizer-2.01_10-14
-wget-1.8.2-15.3
 which-2.16-1
 wireless-tools-26-1
 words-2-21
例2. 段階の異なるRPMデータベースの比較

前述の依存性についても、クエリで確認できます。一般に、依存性は「depname」または「depname＋比較演算子＋バージョン」の形式になります。簡単にいうと、depnameはファイル名、パッケージ名、または内部的に生成された依存性などの任意の文字列です。依存性にはパッケージと同様にバージョンが含まれる場合があり、その場合はこのバージョンの要件（依存性の「比較演算子＋バージョン」の部分）を明示する必要があります。たとえば、あるperlモジュールがperl >= 5.8.0のような依存性を持っているとすると、これはパッケージのインストールのためにperlバージョン5.8.0以上が必要であることを示しています。

他のクエリモードと同様、依存性の内部情報を確認するには、コマンドラインオプションを指定する必要があります。しかし、この場合のパラメータは次のようにもう少し冗長になります。 


rpm -q --requires kernel
rpm -q --provides kernel

これらのコマンドは、他のパッケージに対するカーネルパッケージの依存性、およびカーネルパッケージの存在によって満たされる依存性の一覧を示します。

一方、これらのクエリの方向を変えて、「パッケージXが提供または要求するもの」ではなく、「Yを要求するパッケージ」を確認することも可能です。たとえば、rpm -q --whatrequires glibcによって、glibcを要求するすべてのインストール済みパッケージの一覧が得られます。しかし、この出力には少々疑問があります。glibcを要求するパッケージはそれほど少ないのでしょうか。実際には、ほとんどすべてのパッケージでglibcが必要です。しかし、RPMのコマンドラインの--whatrequiresおよび--whatprovidesは非常に限定された指定になります。つまり、--whatrequiresで出力されるのは、「glibcまたはglibc内部のライブラリを要求するインストール済みパッケージ」ではなく、「glibcを明示的に要求するパッケージ」になります。これは不便なようにも思えますが、「glibcという名前のパッケージを要求するもの」、「glibcパッケージが提供するものを要求するもの」、および「glibcパッケージ内部のファイルを要求するもの」をRPMデータベースに問い合わせることによって、glibcを要求するものに関する情報がかなり得られます。しかし、これではやや複雑になります。幸い、こうしたことは通常は不要です。これらのコマンドの詳細については、例3「glibcを必要とするものの特定」を参照してください。 

rpm -q --whatrequires glibc > /tmp/glibc-dependencies.txt
rpm -q --provides glibc | xargs rpm -q --whatrequires >> /tmp/glibc-dependencies.txt
rpm -ql glibc | xargs rpm -q --whatrequires >> /tmp/glibc-dependencies.txt
sort -u /tmp/glibc-dependencies.txt | less
例3. glibcを必要とするものの特定

インストール済みのパッケージについてRPMデータベースに問い合わせる方法を学習すれば、インストールしていない個別のパッケージについて同様の問い合わせを行う方法がわかります。ファイルシステム上のパッケージについてクエリを実行するには、-qの-pサブモードを使用します。たとえば、bash-2.05b-31.i386.rpmというファイルがあるとすると、そのパッケージ自体に対するrpm -qiコマンドから得られるのと同じ情報を（そのパッケージをインストールする前に）rpm -qi -p bash-2.05b-31.i386.rpmの呼び出しによって確認できます。またrpm -ql -p bash-2.05b-31.i386.rpmによって、そのパッケージに含まれているファイルの一覧が得られます。前述のクエリモードのほとんどは、個別のパッケージに対しても機能します。これは、パッケージをインストールするかどうかを判断するときに特に役立ちます。

RPMはシステムにインストールされているあらゆるパッケージに関して豊富な情報を保持しているため、いくつかの健全性チェックを実行できます（たとえば、必要なファイルが削除されていないかどうかなど）。これは、（-Vによって呼び出される）RPMの検証モードで実行します。このモードはクエリモードに類似していますが、検証は単にシステムを調べるための手段ではなく、これを使用してインストールされているシステムの健全性、およびインストールされているパッケージの依存性が満たされていること（Dependency Closure）を保証できます。

「RPMはシステムにインストールされているあらゆるパッケージに関して豊富な情報を保持しているため、いくつかの健全性チェックを実行できます。」

たとえば、ファイル/etc/bashrcが変更されている可能性があるとします。これが事実かどうかを確認するには、同じバージョンのbashを実行している新規インストールした正常なシステムとそのファイルを比較することもできますが、RPMではすぐに確認できます。最初のステップは、このファイルの元になっているパッケージを確認することです。これは-qf /etc/bashrcによって特定でき、setupパッケージがこのファイルを保持していることがわかります。次に、rpm -V setupによってRPMの検証モードを呼び出します。これの出力は、使用しているシステムによってやや異なります。たとえば、筆者のシステムでは、その出力は次のとおりです。 

S.5....T c /etc/printcap
..?..... c /etc/securetty

出力の最初のカラムはファイルの状態で、ここで関係するのはこの部分です。この場合、ファイルのサイズ、MD5チェックサム、およびタイムスタンプが、RPMで前提されているものと異なることがわかります（筆者の/etc/printcapが編集されている証拠）。表1「rpm -Vの凡例」に各フィールドの意味を示していますが、これはrpmのmanページでも確認できます。 

位置	記号	意味
1	S	ファイルサイズの不一致
2	M	モードまたはパーミッションの不一致
3	5	チェックサムの不一致
4	D	デバイスのメジャーまたはマイナー番号の不一致
5	L	シムリンクの変更
6	U	ユーザ所有権の変更
7	G	グループ所有権の変更
8	T	最終更新日時の変更
表1.rpm -V の凡例

同様に、任意のパッケージ内のファイルが変更、削除、または破壊されていないかどうかも確認できます。これはrpm -Vaコマンドで確認できます。このコマンドは、完了までに相当な時間がかかるので注意してください（RPMが管理するあらゆるファイル、つまりファイルシステム上のほとんどすべてのファイルのチェックサムが行われます）。しかし、これは完全な検査なので、システムのインストール後に加えられた変更について詳細な情報が得られます。この検証モードは、同様にシステムの変更を確認できるTripwireやSamhainのようなソフトウェアの代わりとみなすことはできません。RPMはシステムの変更データを追跡しますが、このタスクに適した本格的なソフトウェアでは、より高度な暗号化技術が使用され、ファイルの妥当性だけでなく、ファイルのチェックサムのリストの妥当性も保証できます。このコマンドにはより高速なバージョンもあり、これによって満たされていない依存性を確認できます。rpm -Va --nofilesでは、すべてのパッケージについて検証が実行されますが、各ファイルの詳細まではチェックされません。

パッケージのインストールと削除

クエリを実行するデータを実際に変更できなければ、あらゆるクエリが無意味になりますが、RPMの場合、これはパッケージのインストールと削除を意味します。従来、インストールと削除はコマンドラインで実行され、この記事でもそれが中心ですが、インストールを実行するためのかなり新しいGUIがあり、これによってインストールの一部を大幅に簡略化できます。

クエリーや検証の場合と同様に、rmpコマンドに新しいモードを導入します。実は複数のモードを導入しますが、それらは相互に密接な関連があります。最初のものは最も基本的なモードで、パッケージのインストールです。このコマンドラインモードは-iであり、これは容易に予想できるようにインストールを表しています（このコマンドには-qはありません。rpm -q -iとrpm -iには大きな違いがあり、前者の主要なモードは-qで、後者の主要なモードは-iです）。このコマンドの使用法は非常に簡単で、rpm -i filename.rpmとなります。これによって、1つのパッケージ（または複数のパッケージ — このコマンドでは複数のファイルのリストを指定できます）がインストールされ、パッケージのインストールが成功すると出力はありません。しかし通常、特に複数のパッケージや大規模なパッケージの場合、処理が完了するまで時間を要することがあるので、出力を確認できる方が好都合です。そこで、前述の-qlvのように、-vサブモードを付加すると、各パッケージがインストールされるにしたがって、その名前がrpmによって表示されます。これでも改善になりますが、さらに-hサブモードを追加すると、rpmはパッケージのインストール状況をプログレスバーで示します。これら3つのパラメータは多くの場合に一緒に使用されるので、通常、rpm -ivh filename.rpmとなります。

インストールはRPMの世界では特別な意味があります。パッケージを取り上げ、競合がないかどうかを確認し、競合がない場合にそれをインストールします。欠落しているのは、多くのユーザが当然と考える1つのステップです。古いバージョンのパッケージがインストールされている場合、新しいバージョンをインストールする一方で古いバージョンを削除します。これでパッケージが実質的にアップグレードされます。インストール済みの新しいバージョンのパッケージに対して-iを使用すると、おそらくエラーメッセージが表示されます。たとえば、rpm -i /tmp/wget-1.8.2-15.3.x86_64.rpmコマンドを実行すると、例4「インストールエラーメッセージの例」のようなメッセージが生成される場合があります。 

file /usr/bin/wget from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-1.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-2.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-3.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info-4.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/info/wget.info.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
file /usr/share/man/man1/wget.1.gz from install of wget-1.8.2-15.3 conflicts with file from package wget-1.8.2-15
例4. インストールエラーメッセージの例

このエラーメッセージは、パッケージの新しいバージョンと古いバージョンの間に競合がある（つまり、両方のパッケージに同じファイルがある）ことを示しています。RPMがこのように動作し、アップグレードしようとするユーザの意向に背く原因は何でしょうか。基本的に、これは同じ名前の複数のパッケージがインストールされる場合があるという事実と関連しています。これは、カーネルパッケージでは特に明らかです（rpm -q kernelを実行すると、カーネルの数を確認できます）。これは広く利用される機能ではありませんが、それでも存在しています。

しかし、RPMにはアップグレードモードが用意されており、ユーザの期待どおりに動作します。このモードは、「このパッケージがインストールされていなければインストールする、このパッケージの古いバージョンがインストールされていればアップグレードする」というものです。これは-Uモードで、（-Uvhというパラメータ指定も含めて）-iに非常によく似た動作をしますが、よりユーザの意向に沿って動作します。パッケージのインストールまたはアップグレードでは、ほとんどの場合、使用すべきコマンドは-Uvhです。

第3のインストールモードとして、-Fで表されるフレッシュというモードがあります。-Fは-Uと似ており、インストールされているパッケージをアップグレードしますが、1つの制限が加わります。インストール済みのパッケージと同じ名前ではないパッケージは無視されます（例5「フレッシュモードの使用例」を参照）。 

# rpm -q wget gaim
wget-1.8.2-15
package gaim is not installed
# rpm -Fvh wget-1.8.2-15.3.x86_64.rpm gaim-0.75-1.3.0.x86_64.rpm
Preparing...                ########################################### [100%]
   1:wget                   ########################################### [100%]
# rpm -q wget gaim
wget-1.8.2-15.3
package gaim is not installed
例5. フレッシュモードの使用例

基本的にフレッシュが役立つのは、適用するファイル（セキュリティアップデートなど）で一杯のディレクトリがあり、一方で多数の新しいパッケージを一度にインストールしたくないような場合です。rpm -Fvh *.rpmコマンドを実行すると、rpmは各パッケージを調べ、古いバージョンがインストールされているパッケージだけをアップグレードします。

パッケージの削除は、パッケージのインストールやアップグレードよりもはるかに簡単です。パッケージを削除するにはrpm -e packagenameコマンドを実行しますが、その場合、これによって依存性が壊れないことが前提になります。次のことに注意が必要です。ユーザが必要性を認識しておらず、RPM依存性も持たないパッケージを削除した場合、簡単にシステムが破壊される可能性があります。RPMはソフトウェア相互間の依存性に関する情報を保持しているだけであり、OpenOffice.orgへのユーザの依存性に関する情報は持ち合わせていません。パッケージを削除しても安全かどうかを判定するには、前述のクエリコマンド、特に-qiおよび-qlでパッケージを確認します。

インストールについて確認していくと、いずれ依存性が問題になります。RPMのデフォルトでは、パッケージが依存しているものがすべてインストールされていないかぎり、そのパッケージはインストールできません。経験があるかも知れませんが、使用する必要のあるパッケージ名がわからないため、依存性が明らかでない場合もあります（たとえば、libc.so.6はglibcパッケージの一部です。しかし、これはglibcが標準Cライブラリを提供し、libcがそのライブラリの1つの名前であることを知らないユーザには自明ではありません）。この問題に対応するため、RPMには支援機能が用意されています。RPMは相当なパッケージ情報を保持していますが、インストールされていないパッケージの情報まではわかりません。幸い、これはRed Hat Enterprise Linuxのrpmdb-redhatまたはFedora Coreのrpmdb-fedoraパッケージによって、ある程度まで実現できます。このパッケージを（yum、up2dateを使用するか、またはミラーから）インストールすると、RPMは依存性解決の提示を自動的に開始します（例6「パッケージ依存性提示の例」を参照）。これによって依存性に伴う多くの問題が解決されますが、失敗する場合もあります。それは特に、サードパーティ製パッケージが他のサードパーティ製パッケージに依存している場合です。それでも、このパッケージは非常に便利です。 

# rpm -Uvh gaim-0.75-1.3.0.x86_64.rpm
error: Failed dependencies:
        libnss3.so()(64bit) is needed by gaim-0.75-1.3.0
        libnss3.so(NSS_3.2)(64bit) is needed by gaim-0.75-1.3.0
        libnss3.so(NSS_3.3)(64bit) is needed by gaim-0.75-1.3.0
        libsmime3.so()(64bit) is needed by gaim-0.75-1.3.0
        libsoftokn3.so()(64bit) is needed by gaim-0.75-1.3.0
        libssl3.so()(64bit) is needed by gaim-0.75-1.3.0
        libssl3.so(NSS_3.2)(64bit) is needed by gaim-0.75-1.3.0
    Suggested resolutions:
        mozilla-nss-1.4.1-18.x86_64.rpm
例6. パッケージ依存性提示の例

依存性の問題にもかかわらず、特定のパッケージをインストールする必要がある場合も考えられます。RPMは強制力のある--forceおよび--nodepsパラメータをインストール関連モードと削除モードの両方に提供します。これらは、それぞれ競合と依存性を無視します。これらのパラメータを使用するとパッケージのインストールは容易になりますが、ほとんどの場合、そのパッケージは機能せず、また他のソフトウェアが使用できなくなる場合もあります。実行する操作について詳細がわからず、また無効にする競合や依存性の影響について完全に理解していない場合は、これらのオプションを使用しないでください。このオプションが使用されたケースを検出する場合は、前述のrpm -Va --nofilesで、この種のエラーをレポートできます。--forceと--nodepsを使用すると、RPMが備えている安全機能の多くがスキップされることに注意してください。

パッケージのインストールでなく、その内部のファイルが1-2個必要なだけという場合もあります。こうしたケースでも多くの場合にパッケージをインストールできますが、そうしたくないこともあるでしょうし、また、そのパッケージに受容できない依存性があると、やや強引な方法でインストールすることにもなりかねません。前述のように、RPMパッケージは理想的なtarballまたはzipファイルとみなすことができるため、当然それらのファイルフォーマットと同じようにパッケージの内容を抽出することが可能です。RPM自体ではこれを実行できませんが、rpm2cpioというユーティリティが用意されており、これによってパッケージをcpioアーカイブといわれるものに変換できます（cpioアーカイブはtarballによく似ています）。RPMパッケージの内容を抽出するには、どこかにディレクトリを作成し、このディレクトリに移動して、rpm2cpio packagename | cpio -idコマンドを入力します。ここで、packagenameはパッケージファイルの場所です。これによってパッケージの内容がカレントディレクトリに抽出され、必要なファイルを簡単に取得できます。

yum、up2date、およびredhat-config-packages

RPMベースのディストリビューションを管理するときは、rpmコマンドの機能に関する詳細な知識が不可欠ですが、手動でRPMパッケージをダウンロードし、多数のマシン上でアップデートを繰り返す作業はかなり骨が折れます。ファイルをコピーしたり、複数のマシンにログインしたりするだけでも大変ですが、依存性がからむと、特に多数のマシンが関係する場合、そうした作業はほとんど非現実的になることがあります。幸い、コミュニティとRed Hatのような企業の両方が、この問題にさまざまな形で取り組んでいます。Red Hat Enterprise LinuxにはRed Hat Update Agent（up2date）が付属し、Fedora Coreには2つのソリューション（yumとup2date）が同梱されています。

yumは、Fedora Coreの優れたツールの1つです。yumという名前はYellow Dog Updater, Modifiedの略語で、その主な用途（最新のセキュリティ修正によるシステムアップデートの保証）を反映しています。yumが特に優れているのは、複数のサイトをパッケージのソースとして統合する機能です。つまり、コンフィギュレーションファイルに数行追加するだけで、Fedora Coreの公式パッケージを入手できると同時に、コミュニティのメンバーが作成した任意のリポジトリにアクセスできます。

Fedora Coreでは、そのインストールと同時にアップデートを入手できるようにyumが設定されています。実際には、最初に行う必要のある作業の１つは、利用できるアップデートがあるかどうかを確認し、それらをできるかぎり早期に適用することです（新規に導入されたシステムには必ずアップデートがあり、それが現代のすべてのオペレーティングシステムの特徴になっている）。このチェックを実行するには、yum check-updateコマンドを入力します。その出力は、例 7「パッケージ依存性提示の例」のようになります。 

Gathering header information file(s) from server(s)
Server: Fedora Core 1 - x86_64 - Base
Server: Fedora Core 1 - x86_64 - Released Updates
Finding updated packages
Downloading needed headers
Name                                Arch   Version                  Repo
--------------------------------------------------------------------------------
openssl                             x86_64 0.9.7a-33.10             updates-released
openssl-devel                       x86_64 0.9.7a-33.10             updates-released
例7. パッケージ依存性提示の例

利用できる新しいソフトウェアがわかったら、yum update packagename packagename packagenameコマンドで一度にいくつかのパッケージをアップデートするか、またはyum updateコマンド（パッケージを具体的に指定しません）ですべてのアップデートを実行します。yumはあらゆる依存性を計算し、ユーザによる確認を促し、パッケージをダウンロードし、チェックサムを検証し（ダウンロードエラーから保護）、そしてパッケージの暗号署名を確認するように設定されている場合はそれを実行します（不正に改変されたパッケージから保護）。ダウンロードおよびインストール処理に時間がかかることがありますが、ユーザのシステムに重要なセキュリティアップデートを適時に適用することは不可欠です。実際には、ユーザはfedora-announce-listに加入し、アップデートパッケージやセキュリティ問題に関する警告、その他の重要なアナウンスメントをFedoraコミュニティから受け取ることが強く推奨されます。このリスト、およびその他のFedora関連リストには、http://fedora.redhat.com/participate/communicate/からアクセスできます。

またRed Hat Update AgentがRed Hat Linux 6.2で利用できるようになり、その後のリリースに標準で同梱されています（RHL 6.2に含まれる初期バージョンのup2dateはRHNサーバに接続しませんでした。しかし、アップデートパッケージがRHNとともにリリースされ、RHL 6.2ユーザはRHNからアップデートを入手できました）。これは、Red Hat Enterprise Linuxでもサポートされているアップデートメカニズムです。コマンドラインインターフェースとグラフィカルインターフェースの使用法はいずれもRed Hat Enterprise LinuxとFedora Coreで非常によく似ていますが、Red Hat Enterprise Linuxではup2dateでユーザアカウントを作成する必要があるという重要な違いがあります。ユーザがRed Hat Enterprise Linuxシステムをアクティブ化または購入した際に使用したのと同じアカウントを使用して、up2dateでユーザのシステムを登録することが重要です。この環境でup2dateを使用することの利点の1つは、ユーザのシステムが登録済みのRed Hat Enterprise Linuxインストールなので、ユーザの要求に対応するサービスで優先帯域幅が使用されることです。従って、ミラーを見つけたり、コンフィギュレーションファイルを変更したりする必要がなく、Fedora Coreでyumまたはup2dateを使用するときに必要とされるような他の方法は不要になります。FC1以来、up2dateは、up2date専用プロトコルに対応したRed Hatサーバ、またはyumプロトコルに対応したyumサーバのどちらかと直接接続する従来のモードで機能できます（実際には、aptなど他のいくつかのプロトコルにも対応していますが、yumが標準なので、ここではこれを取り上げます）。up2dateとyumはほとんど同じ機能セットをサポートしていますが、一部のユーザは以前からup2dateに親しんでおり、またup2dateのより高度な機能の利便性を認めています。また、up2dateにはアップデートのダウンロードとインストールのための使いやすいグラフィカルインターフェースが用意され、これは一部のユーザからyumのようなコマンドラインユーティリティよりも好まれています。

Fedora Coreでは、デフォルトで、yumと同じようにup2dateも公式のFedoraサーバと交信してアップデートを入手できるように設定されています。またRed Hat Enterprise Linuxでも、up2dateは専用のRed Hat Networkサーバと優先帯域幅で交信するように設定されています。up2dateコマンドを実行するか、またはパネル上のMain MenuでSystem Tools -> Red Hat Networkを選択して、利用できるアップデートを一覧表示し、次にグラフィカルウィザードに従って処理の手順を進めます。コマンドラインを好む場合は、up2date -lコマンドを実行すると、yum check-updateと同じような出力が異なるフォーマットで表示されます。さらにup2date -uコマンドを実行すると、依存性を満たしながら、すべてのパッケージが自動的にアップデートされます。デフォルトでは、up2dateはカーネルをアップグレードしないことに注意してください。これは、カーネルの自動アップグレードが信頼できなかった時代のなごりです。現在では自動アップグレードはまったく安全になっているので、up2dateの除外リストの編集か（up2date -configureを実行し、次にExclusionsタブをクリック）、またはup2date -uコマンドラインでの-f変更子の使用を検討する必要があります。これによって、up2dateの単一の呼び出しでパッケージの除外が無効になり、カーネルのインストールが可能になります。

yumとup2dateの優れた機能の1つは、パッケージの外部リポジトリを使用できることです。特定のプロジェクトのための小規模なリポジトリ（Arjan van de Ven氏のkernel 2.6リポジトリなど）から、ポピュラなfreshrpms.netのような追加ソフトウェアの包括的な大規模リポジトリや、初期のfedora.usリポジトリ（のちのFedora Projectの基盤）にいたるまで、多数のリポジトリがあります。リポジトリの追加方法はup2dateとyumで異なりますが、両方とも目的のリポジトリのURLという同じ情報が必要です。

yumでリポジトリを追加するには、/etc/yum.confファイルを編集します。このファイルには複数のセクションがあり、それぞれ角括弧に入った名前でラベルされています。最初のセクションは[main]で、ここにはyum自体のさまざまな設定が記述されています。これらの設定はyumのmanページで詳しく説明されていますが、さしあたって無視することにします。次のセクションは[base]で、これはFedora Core 1で最初に提供されたパッケージが含まれるリポジトリに対応しています。ここで依存性が満たされ、ベースになるパッケージを容易にインストールできるようになります。このセクションには、nameとbaseurlという2つのエントリがあります。これらは[main]以外のあらゆるセクションで必要であり、容易に推測できるように、それぞれリポジトリの記述名とリポジトリのベースURLです。さらに、公式リリースが含まれる[updates-released]セクションとコメントアウトされている[updates-testing]セクションがあります（後者のコメントアウトを外すとアップデートパッケージのテストに役立ちますが、リリース前のすべてのソフトウェアでは、破損が発生する場合があることに注意してください）。リポジトリのURLを追加するには、ファイルの末尾に新しいセクションを追加し、[repository]と命名して（repositoryは追加するリポジトリの名前で、これを決めるのはユーザです）、そのリポジトリを説明するname=を追加します。次に、既存のURLにマッピングするbaseurl=を追加して、ファイルを保存し、yum check-updateを実行して、それが機能することを確認します。

up2dateも似ていますが、この場合のファイルは/etc/sysconfig/rhn/sourcesであり、/etc/yum.confではありません。このファイルにはいくつかのサンプルがあります。ベースOS自体のエントリを確認するには、fedora-core-1を検索します（これはyum.confの[main]セクションに似ています）。しかし、このファイルでは各リポジトリは単一の行で表され、最初にリポジトリのタイプが記載され（この場合はyum）、次に説明ラベル（yum.confの角括弧に入っているラベルと同様）、そしてリポジトリのURLと続きます。変更したファイルを保存し、up2date -lを実行して、ファイルに問題がないかどうかを確認します。

必要なリポジトリを含めるyumまたはup2dateの設定ができたら、利用できるソフトウェアの確認を開始できます。yumで利用できるすべてのパッケージを一覧表示するには、yum listコマンドを入力します。up2dateから同様の一覧を表示するには、up2date --showallコマンドを使用します。

しかし、大きなプログラムのダウンロードとインストールは行わない、または必要なプログラムが正確にわからない場合もあります。redhat-config-packagesという第3のユーティリティがあり、これは3つのうちで最新のものです。その名前はやや特異ですが、これには非常に重要な機能があります。これはRed Hat Enterprise LinuxとFedora Coreの出荷時のソフトウェア構成とそれらのソフトウェアを収録しているCDの情報を保持しています。これによってユーザは、名前を直接指定するのではなく、インストールプログラムで示されるのと同じカテゴリに基づいてパッケージを選択できます。この方式ははるかにわかりやすく、プログラムの名前を知らなくても、必要なプログラムをすばやく見つけることができます。図1「redhat-config-packages」は、利用できるカテゴリの一覧を示しています。パッケージの選択は簡単で、カテゴリを選択し、いくつかのチェックボックスをクリックし、Updateボタンを押すだけです。実行すると、そのパッケージのインストールと欠落している依存性の解決のために必要なCDを挿入するように求められます。


図1. redhat-config-packages

結論

この記事では、RPM自体とそのユーティリティの概略について説明しました。これは多岐にわたる奥深いテーマですが、特にRPMの内部の仕組みを理解すれば、少数のコマンドだけで生産的に利用できます。さらに学習する最良の方法は、実際に使ってみることのほかに、Fedoraコミュニティに参加することです。多くのメーリングリストがあります。特にfedora-listはFedoraの一般ユーザを対象としており、Fedora固有の問題で役立ちます。fedora-listやその他のLinux関連のメーリングリストに参加するには、http://listman.redhat.com/のRed Hatメーリングリストサーバにアクセスしてください。また活発で有益なコミュニティを持つRPMのリストもあり、これにもRed Hatメーリングリストサーバからアクセスできます。

この記事のパート2では、RPMをマスタする次の段階に進み、ユーザ独自のRPMパッケージを作成します。必ずしも明らかなことではありませんが、パッケージの作成方法がわかると、ソフトウェアの正しいパッケージングから得られる柔軟性、信頼性、および予測可能性によって、ただちに時間を節約でき、RPMベースのLinuxディストリビューションの処理がはるかに容易になります。

執筆者について

Chip TurnerはRed Hatに3年間勤務しており、Red Hat Networkのチーフ設計者です。また、彼はFedora CoreとRed Hat Enterprise Linux用にperlパッケージ、perlの全モジュール、およびspamassassinを保守し、RPMのRPM2 perlバインディングやその他のいくつかのCPAN perlモジュールを作成しています。余暇には愛犬とたわむれ、雑談を楽しんでいます。