Novell Doc: 管理ガイド - RPM—パッケージマネージャ

4.2 RPM—パッケージマネージャ

RPM (RPM Package Manager)がソフトウェアパッケージを管理するのに使用されます。RPMの主要コマンドは、rpmとrpmbuildです。ユーザ、システム管理者、およびパッケージの作成者は、強力なRPMデータベースでクエリーを行って、インストールされているソフトウェアに関する情報を取得できます。

基本的にrpmには、ソフトウェアパッケージのインストール、アンインストール、アップデート、RPMデータベースの再構築、RPMベースまたは個別のRPMアーカイブの照会、パッケージの整合性チェック、およびパッケージへの署名の5種類のモードがあります。rpmbuildは、元のソースからインストール可能なパッケージを作成する場合に使用します。

インストール可能なRPMアーカイブは、特殊なバイナリ形式でパックされています。それらのアーカイブは、インストールするプログラムファイルとある種のメタ情報で構成されます。メタ情報は、ソフトウェアパッケージを設定するためにrpmによってインストール時に使用されるか、または文書化の目的でRPMデータベースに格納されています。通常、RPMアーカイブには拡張子.rpmが付けられます。

ヒント: ソフトウェア開発パッケージ

多くのパッケージにおいて、ソフトウェア開発に必要なコンポーネント(ライブラリ、ヘッダ、インクルードファイルなど)は、別々のパッケージに入れられています。それらの開発パッケージは、最新のGNOMEパッケージのように、ソフトウェアを自分自身でコンパイルする場合にのみ、必要になります。それらのパッケージは、パッケージalsa-devel、gimp-devel、kdelibs3-develなどのように、名前の拡張子-develで識別できます。

4.2.1 パッケージの信頼性の検証

RPMパッケージにはGnuPG署名があります。フィンガープリントを含む鍵は、次のとおりです。

1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build@suse.de>
Key fingerprint = 79C1 79B2 E1C8 20C1 890F  9994 A84E DAE8 9C80 0ACA

rpm --checksig package-1.2.3.rpmコマンドを使用して、RPMパッケージの署名を検証し、パッケージが本当にSUSEから提供されたものか、他の信頼できる機関から提供されたものか判定できます。これは、インターネットからアップデートパッケージを入手する場合には、特に推奨されます。SUSEのパブリックパッケージ用の署名キーは通常、/root/.gnupg/にあります。バージョン8.1以降、キーは、ディレクトリ/usr/lib/rpm/gnupg/も格納されており、一般ユーザがRPMパッケージの署名を検証できるようになっています。

4.2.2 パッケージの管理:インストール、アップデート、およびアンインストール

通常RPMアーカイブのインストールはとても簡単です。rpm -i package.rpmの用に入力します。このコマンドで、パッケージをインストールできます。ただし、依存関係が満たされており、他のパッケージとの競合がない場合に限られます。rpmでは、依存関係の要件を満たすためにインストールしなければならないパッケージがエラーメッセージで要求されます。バックグランドで、RPMデータベースは競合が起きないようにします。ある特定のファイルは、1つのパッケージだけにしか属せません。別のオプションを選択すると、rpmにこれらのデフォルト値を無視させることができますが、この処置を行うのは専門知識のある人に限られます。それ以外の人が行うと、システムの整合性を危うくするリスクが発生し、システムアップデート機能が損なわれる可能性があります。

-Uまたは--upgradeと-Fまたは--freshenの各オプションは、パッケージをアップデートするのに使用できます。たとえば、rpm -F package.rpmです。このコマンドは、古いバージョンのファイルを削除し、新しいファイルをただちにインストールします。2つのバージョン間の違いは、-Uがシステムに存在していなかったパッケージをインストールするのに対して、-Fがインストールされていたパッケージを単にアップデートする点にあります。アップデートする際、rpmは、以下のストラテジーに基づいて設定ファイルを注意深くアップデートします。

設定ファイルがシステム管理者によって変更されていない場合、rpmは新しいバージョンの適切なファイルをインストールします。システム管理者は、何も行う必要はありません。
アップデートの前に設定ファイルがシステム管理者によって変更されている場合、rpmは変更されたファイルに拡張子.rpmorigまたは.rpmsave (バックアップファイル)を付けて保存し、新しいパッケージからファイルをインストールします。ただしこれは、元々インストールされていたファイルと新しいファイルのバージョンが異なる場合に限ります。異なる場合は、バックアップファイル(.rpmorigまたは.rpmsave)と新たにインストールされたファイルを比較して、新しいファイルに再度、変更を加えます。後ですべての.rpmorigと.rpmsaveファイルを必ず削除して、今後のアップデートで問題が起きないようにします。
設定ファイルがすでに存在しており、またnoreplaceラベルが.specファイルで指定されている場合、.rpmnewファイルが作成されます。

アップデートが終了したら、.rpmsaveファイルと.rpmnewファイルは、比較した後、将来のアップデートの妨げにならないように削除する必要があります。ファイルがRPMデータベースで認識されなかった場合、ファイルには拡張子.rpmorigが付けられます。

認識された場合には、.rpmsaveが付けられます。言い換えれば、.rpmorigは、RPM以外の形式からRPMにアップデートした結果として付けられます。.rpmsaveは、古いRPMから新しいRPMにアップデートした結果として付けられます。.rpmnewは、システム管理者が設定ファイルに変更を加えたかどうかについて、何の情報も提供しません。それらのファイルのリストは、/var/adm/rpmconfigcheckにあります。設定ファイルの中には(/etc/httpd/httpd.confなど)、操作が継続できるように上書きされないものがあります。

-Uスイッチは、単に-eオプションでアンインストールして、-iオプションでインストールする操作と同じではありません。可能なときは必ず-Uを使用します。

パッケージを削除するには、rpm -e packageを入力します。rpmは、解決されない依存関係がない場合にのみパッケージを削除します。他のアプリケーションがTcl/Tkを必要とする限り、Tcl/Tkを削除することは理論的に不可能です。その場合でも、RPMはデータベースに援助を要求します。他の依存関係がない場合でも、また、どのような理由、特殊な環境であってもそのような削除が不可能であれば、--rebuilddbオプションを使用してRPMデータベースを再構築するのが良いでしょう。

4.2.3 RPMとパッチ

システムの運用上のセキュリティを保証するには、ときどきアップデートパッケージをシステムにインストールする必要があります。以前は、パッケージ内のバグは、パッケージ全体を交換しなければ取り除けませんでした。大きいパッケージの場合、その中の小さなファイルにバグがあると、膨大な量のデータになってしまうことがありました。しかし、SUSE RPMを使用すると、パッケージ内にパッチをインストールできます。

最も重要な考慮事項について、pineを例として説明します。

パッチRPMはシステムに適したものか。

これを検査するには、はじめにインストールされたパッケージでクエリーを行います。pineでは、以下のコマンドを実行します。

rpm -q pine
pine-4.44-188

パッチRPMがこのバージョンのpineに適しているかどうかを検査します。

rpm -qp --basedon pine-4.44-224.i586.patch.rpm 
pine = 4.44-188
pine = 4.44-195
pine = 4.44-207

このパッチは、3種類のバージョンのpineに適しています。例でインストールされたバージョンもリストされています。パッチはインストールできます。

どのファイルがパッチで置き換えられるか。

パッチの影響を受けるファイルは、パッチRPMで簡単に見つけられます。rpmの-Pパラメータを使用すると、特殊なパッチ機能を選択できます。次のコマンドでファイルをリストします。

rpm -qpPl pine-4.44-224.i586.patch.rpm
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine

パッチがすでにインストールされていれば、次のコマンドを使用します。

rpm -qPl pine
/etc/pine.conf
/etc/pine.conf.fixed
/usr/bin/pine

パッチRPMをどのようにシステムにインストールするか。

パッチRPMは、通常のRPMと同様に使用されます。唯一の違いは、適切なRPMがすでにインストールされていなければならない点です。

どのパッチがシステムにインストールされており、それらはどのパッケージバージョンのものか。

システムにインストールされているすべてのパッチのリストは、コマンドrpm -qPaで表示できます。(この例のように)新しいシステムに1つのパッチだけがインストールされている場合、リストは次のようになります。

rpm -qPa
pine-4.44-224

後日、オリジナルとしてインストールされていたパッケージのバージョンを知りたい場合、その情報はRPMデータベースから得られます。pineの場合、その情報は次のコマンドで表示できます。

rpm -q --basedon pine
pine = 4.44-188

RPMのパッチ機能に関する情報を含む詳細な情報は、man rpmコマンドとrpmbuildコマンドのマニュアルページで収集できます。

4.2.4 デルタRPMパッケージ

デルタRPMパッケージには、RPMパッケージの新旧バージョン間の違いが含まれています。デルタRPMパッケージを古いRPMに適用すると、まったく新しいRPMになります。デルタRPMパッケージは、インストールされたRPMとも互換性があるので、古いRPMのコピーを保管する必要はありません。デルタRPMパッケージは、パッチRPMよりもさらに小さく、パッケージをインターネット上で転送するのに便利です。欠点は、デルタRPMが組み込まれたアップデート操作の場合、そのままのRPMまたはパッチRPMに比べて、CPUサイクルの消費が目立って多くなることです。

prepdeltarpm、writedeltarpm、およびapplydeltarpmバイナリは、デルタRPMスィート(deltarpmパッケージ)の一部であり、デルタRPMパッケージの作成と適用に際して役立ちます。次のコマンドを使用して、new.delta.rpmというデルタRPMを作成します。次のコマンドでは、old.rpmおよびnew.rpmが存在することが前提となります。

prepdeltarpm -s seq -i info old.rpm > old.cpio
prepdeltarpm -f new.rpm > new.cpio
xdelta delta -0 old.cpio new.cpio delta
writedeltarpm new.rpm delta info new.delta.rpm

最後に、一時作業ファイルold.cpio、new.cpio、およびdeltaを削除します。

古いパッケージがすでにインストールされていれば、applydeltarpmを使用して、ファイルシステムから新たにRPMを構築できます。

applydeltarpm new.delta.rpm new.rpm

ファイルシステムにアクセスすることなく、古いRPMから構築するには、-rオプションを使用します。

applydeltarpm -r old.rpm new.delta.rpm new.rpm

技術的な詳細については、『/usr/share/doc/packages/deltarpm/README』を参照してください。

4.2.5 RPMクエリー

-qオプションを使用すると、rpmはクエリーを開始し、(-pオプションを追加することにより) RPMアーカイブを検査できるようにして、インストールされたパッケージのRPMデータベースでクエリーを行えるようにします。必要な情報の種類を指定する複数のスイッチを使用できます。詳細については、表 4-1を参照してください。

表 4-1 最も重要なRPMクエリーのオプション

-i	パッケージ情報
-l	ファイルリスト
-f FILE	ファイルFILEを含むパッケージでクエリーを行います(FILEにはフルパスを指定する必要があります)。
-s	ステータス情報を含むファイルリスト(-lを暗示指定)
-d	ドキュメントファイルだけをリストします (-lを暗示指定)。
-c	設定ファイルだけをリストします(-lを暗示指定)。
--dump	詳細情報を含むファイルリスト(-l、-c、または-d と共に使用します)
--provides	他のパッケージが--requiresで要求できるパッケージの機能をリストします。
--requires, -R	パッケージが要求する機能
--スクリプト	インストールスクリプト(preinstall、postinstall、uninstall)

たとえば、コマンドrpm -q -i wgetは、例 4-1に示された情報を表示します。

例 4-1 rpm -q -i wget

Name        : wget                         Relocations: (not relocatable)
Version     : 1.9.1                             Vendor: SUSE LINUX AG, Nuernberg, Germany
Release     : 50                            Build Date: Sat 02 Oct 2004 03:49:13 AM CEST
Install date: Mon 11 Oct 2004 10:24:56 AM CEST      Build Host: f53.suse.de
Group       : Productivity/Networking/Web/Utilities   Source RPM: wget-1.9.1-50.src.rpm
Size        : 1637514                          License: GPL
Signature   : DSA/SHA1, Sat 02 Oct 2004 03:59:56 AM CEST, Key ID a84edae89c800aca
Packager    : http://www.suse.de/feedback
URL         : http://wget.sunsite.dk/
Summary     : A tool for mirroring FTP and HTTP servers
Description :
Wget enables you to retrieve WWW documents or FTP files from a server.
This can be done in script files or via the command line.
[...]

オプション-fが機能するのは、フルパスで完全なファイル名を指定した場合だけです。必要な数のファイル名を指定します。たとえば、次のコマンドを実行します。

rpm -q -f /bin/rpm /usr/bin/wget

出力は次のとおりです。

rpm-4.1.1-191
wget-1.9.1-50

ファイル名の一部分しかわからない場合は、例 4-2に示すようなシェルスクリプトを使用します。実行するときに、ファイル名の一部を、パラメータとして示されるスクリプトに渡します。

例 4-2 パッケージを検索するスクリプト

#! /bin/sh
for i in $(rpm -q -a -l | grep  $1); do
    echo "\"$i\" is in package:"
    rpm -q -f $i
    echo ""
done

rpm -q --changelog rpmコマンドは、特定のパッケージに関する詳細な変更情報を日付順に表示します。この例は、rpmパッケージに関する情報を示します。

インストールされたRPMデータベースを使うと、確認検査を行うことができます。それらの検査は、-V、-y、または--verifyオプションを使用して開始します。このオプションを使うと、rpmは、パッケージ内にあり、インストール以降変更されたことがあるすべてのファイルを表示します。rpmは、次の変更に関するヒントを表示するのに、8文字の記号を使用します。

表 4-2 RPM確認オプション

5	MD5チェックサム
S	ファイルサイズ
L	シンボリックリンク
T	変更時間
D	メジャーデバイス番号とマイナーデバイス番号
U	所有者
G	グループ
M	モード (許可とファイルタイプ)

設定ファイルの場合は、文字cが表示されます。/etc/wgetrc (wget)に対する変更例を以下に示します。

rpm -V wget
S.5....T c /etc/wgetrc

RPMデータベースのファイルは、/var/lib/rpmに格納されています。パーティション/usrのサイズが 1 GBであれば、このデータベースは、完全なアップデート後、およそ 30 MB占有します。データベースが予期していたよりもはるかに大きい場合は、オプション--rebuilddbでデータベースを再構築するようにします。再構築する前に、古いデータベースのバックアップを作成しておきます。cronスクリプトのcron.dailyは、データベースのコピー(gzip でパックされる)を毎日作成し、/var/adm/backup/rpmdbに格納します。コピー数は/etc/sysconfig/backupにある変数MAX_RPMDB_BACKUPSで制御します(デフォルト:5)。1つのバックアップのサイズは、1GBの/usrに対しておよそ1MBです。

4.2.6 ソースパッケージのインストールとコンパイル

すべてのソースパッケージには、拡張子.src.rpm (ソース RPM)が付けられています。

ヒント: ソースパッケージは、インストールメディアからハードディスクにコピーされ、YaSTを使用して展開できます。ただし、ソースパッケージは、パッケージマネージャでインストール済み([i])というマークは付きません。これは、ソースパッケージがRPMデータベースに入れられないためです。インストールされたオペレーティングシステムソフトウェアだけがRPMデータベースにリストされます。ソースパッケージをインストールする場合、ソースコードだけがシステムに追加されます。

(/etc/rpmrcなどのファイルでカスタム設定を指定していない限り)以下のディレクトリが、/usr/src/packagesの下でrpmとrpmbuildから使用可能でなければなりません。

SOURCES: オリジナルのソース(.tar.gzファイルや.tar.gzファイルなど)とディストリビューション固有の調整ファイル(ほとんどの場合.difファイルや.patchファイル)用です。
SPECS: ビルド処理を制御する、メタMakefileに類似した.specファイル用です。
BUILD: すべてのソースは、このディレクトリでアンパック、パッチ、コンパイルされます。
RPMS: 完成したバイナリパッケージが格納されます。
SRPMS: ソースRPMが格納されます。

YaSTを使ってソースパッケージをインストールすると、必要なすべてのコンポーネントが/usr/src/packagesにインストールされます。ソースと調整はSOURCES、関連する.specファイルはSPECSに格納されます。

警告: システムコンポーネント(glibc、rpm、sysvinitなど)で実験してはいけません。システムが正しく動作しなくなります。

次の例は、wget.src.rpmパッケージを使用します。YaSTでパッケージをインストールすると、次のファイルが作成されるはずです。

/usr/src/packages/SOURCES/nops_doc.diff
/usr/src/packages/SOURCES/toplev_destdir.diff
/usr/src/packages/SOURCES/wget-1.9.1+ipvmisc.patch
/usr/src/packages/SOURCES/wget-1.9.1-brokentime.patch
/usr/src/packages/SOURCES/wget-1.9.1-passive_ftp.diff
/usr/src/packages/SOURCES/wget-LFS-20040909.tar.bz2
/usr/src/packages/SOURCES/wget-wrong_charset.patch
/usr/src/packages/SPECS/wget.spec

rpmbuild -b X /usr/src/packages/SPECS/wget.specコマンドは、コンパイルを開始します。Xは、ビルド処理のさまざまな段階に対して使用されるワイルドカードです(詳細については、--helpの出力またはRPMのドキュメントを参照してください)。以下に簡単な説明を示します。

-bp: /usr/src/packages/BUILD内のソースを用意します。アンパック、パッチしてください。
-bc: -bpと同じですが、コンパイルを実行します。
-bi: -bpと同じですが、ビルドしたソフトウェアをインストールします。警告:パッケージがBuildRoot機能をサポートしていない場合は、設定ファイルが上書きされることがあります。
-bb: -biと同じですが、バイナリパッケージを作成します。コンパイルに成功すると、バイナリパッケージは、/usr/src/packages/RPMSに作成されるはずです。
-ba: -bbと同じですが、ソース RPMを作成します。コンパイルに成功すると、バイナリは/usr/src/packages/SRPMSに作成されるはずです。
--short-circuit: 一部のステップをスキップします。

作成されたバイナリRPMは、rpm -iコマンドまたはrpm -Uコマンドでインストールできます。rpmを使用したインストールは、RPMデータベースに登場します。

4.2.7 buildによるRPMパッケージのコンパイル

多くのパッケージにつきものの不都合は、ビルド処理中に不要なファイルが稼働中のシステムに追加されてしまうことです。これを回避するには、パッケージのビルド先の定義済みの環境を作成するbuildを使用します。このchroot環境を確立するには、build スクリプトが完全なパッケージツリーと共に提供されなければなりません。パッケージツリーは、NFS経由で、またはDVDからハードディスク上で利用できるようにすることができます。build --rpms directoryで、位置を指定します。rpmとは異なり、buildコマンドはソースディレクトリでSPECファイルを探します。(上記の例と同様に)システムで/media/dvdの下にマウントされているDVDでwgetをビルドするには、rootユーザーで次のコマンドを使用します。

cd /usr/src/packages/SOURCES/
mv ../SPECS/wget.spec .
build --rpms /media/dvd/suse/ wget.spec

これで、最小限の環境が/var/tmp/build-rootに確立されます。パッケージは、この環境でビルドされます。処理が完了すると、ビルドされたパッケージは/var/tmp/build-root/usr/src/packages/RPMSに格納されます。

buildスクリプトでは、他のオプションも多数使用できます。たとえば、スクリプトがユーザ独自のRPMを処理するようにするには、ビルド環境の初期化を省略するか、rpmコマンドの実行を上記のビルド段階のいずれかに制限します。build --helpコマンドとman buildコマンドで、詳細な情報が得られます。

4.2.8 RPMアーカイブとRPMデータベース用のツール

Midnight Commander (mc)は、RPMアーカイブの内容を表示し、それらの一部をコピーできます。アーカイブを仮想ファイルシステムとして表し、Midnight Commanderの通常のメニューオプションを使用できます。<F3>キーを使用してHEADERを表示します。カーソルキーと<Enter>キーを使ってアーカイブ構造を表示します。<F5>キーを使用してアーカイブコンポーネントをコピーします。

KDEは、rpmのフロントエンドとしてkpackageツールを提供します。完全装備のパッケージマネージャが、YaSTモジュールとして使用可能です(「第9章ソフトウェアをインストールまたは削除する」を参照してください)。