この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される述語(たとえば、repository、patch、updateなど)の定義については、Section “Definition of Terms”, Chapter 6, Installing or Removing Software, Deployment Guideを参照してください。
Zypperは、パッケージのインストール、更新、削除、およびリポジトリの管理を行うためのコマンドラインパッケージマネージャです。これは特に、リモートソフトウェア管理タスクの実行、またはシェルスクリプトからのソフトウェアの管理で役立ちます。
Zypperの一般的な構文は次のとおりです。
zypper[--global-options]command[--command-options][arguments]...
ブラケットで囲まれたコンポーネントは必須ではありません。一般的なオプションおよびすべてのコマンドのリストについては、zypper helpを参照してください。特定のコマンドのヘルプを参照するには、「zypper help command」と入力します。
Zypperを実行する最も簡単な方法は、その名前の後にコマンドを入力することです。たとえば、システムに必要なすべてのパッチを適用するには、次のコマンドを入力します。
zypper patch
さらに、グローバルオプションをコマンドの直前に入力することによって、1つ以上のグローバルオプションを選択することもできます。たとえば--non-interactiveでは、何も入力を求められることなく、コマンドを実行できます(自動的にデフォルトの解答が適用されます)。
zypper --non-interactive patch
特定のコマンドに固有のオプションを使用する場合は、コマンドの直後にそのオプションを入力します。たとえば、--auto-agree-with-licensesは、ライセンスの確認を求めることなく、システムで必要なすべてのパッチを適用します(自動的に受け入れられます)。
zypper patch --auto-agree-with-licenses
一部のコマンドでは、1つ以上の引数が必要です。たとえば、インストールコマンドを使用する場合、インストールするパッケージを指定する必要があります。
zypper install mplayer
また一部のオプションでは、引数が必要です。次のコマンドでは、すべての既知のパターンが表示されます。
zypper search -t pattern
上記のすべてを結合できます。たとえば、次のコマンドは、冗長モードで、factoryリポジトリからaspell-deとaspell-frパッケージをインストールします。
zypper -v install --from factory aspell-de aspell-fr
--fromオプションは、指定されたリポジトリからパッケージを要求する際に、すべてのリポジトリを(依存関係の解決のため)有効に保ちます。
ほとんどのZypperコマンドには、指定のコマンドのシミュレーションを行うdry-runオプションがあります。このオプションは、テストの目的で使用できます。
zypper remove --dry-run MozillaFirefox
Zypperは、グローバルオプション--userdata stringをサポートします。このオプションを使用して文字列を指定することができます。指定した文字列は、Zypperのログファイルとプラグイン(Btrfsプラグインなど)に書き込まれます。これを使用して、ログファイルでトランザクションにマークを付けたり、トランザクションを特定したりできます。
zypper --userdata string patch
パッケージをインストールまたは削除するには、次のコマンドを使用します。
zypper install package_name zypper remove package_name
Zypperでは、インストールコマンドおよび削除コマンドでパッケージを指定するために、次のようなさまざまな方法が可能です。
zypper install MozillaFirefox
または
zypper install MozillaFirefox-3.5.3
zypper install mozilla:MozillaFirefox
ここでmozillaは、インストールするリポジトリのエイリアスです。
次のコマンドでは、名前の先頭に「Moz」が付くすべてのパッケージがインストールされます。特にパッケージを削除する場合には、慎重に行うことが必要です。
zypper install 'Moz*'
たとえば、パッケージ名がわからないPerlモジュールをインストールする場合は、機能による指定が便利です。
zypper install firefox
機能とともに、アーキテクチャ(x86_64など)またはバージョン、あるいはその両方を指定できます。バージョンの前には、演算子として、<(未満)、<=(以下)、=(等しい)、=>(以上)、または>(より大きい)を付ける必要があります:
zypper install 'firefox.x86_64' zypper install 'firefox>=3.5.3' zypper install 'firefox.x86_64>=3.5.3'
また、パッケージに対するローカルパスまたはリモートパスを指定できます。
zypper install /tmp/install/MozillaFirefox.rpm zypper install http://download.opensuse.org/repositories/mozilla/SUSE_Factory/x86_64/MozillaFirefox-3.5.3-1.3.x86_64.rpm
パッケージのインストールおよび削除を同時に行うには、+/-修飾子を使用します。emacsのインストールとvimの削除を同時に行うには、次のコマンドを使用します。
zypper install emacs -vim
emacsの削除とvimのインストールを同時に行うには、次のコマンドを使用します。
zypper remove emacs +vim
名前の先頭に-が付くパッケージ名がコマンドオプションとして解釈されないようにするには、常に第2引数としてその名前を使用します。これが可能でない場合は、名前の前に--を付けます。
zypper install -emacs +vim # Wrong zypper install vim -emacs # Correct zypper install -- -emacs +vim # same as above zypper remove emacs +vim # same as above
指定したパッケージの削除後に、(その特定のパッケージとともに)不要になったパッケージを自動的に削除したい場合は、--clean-depsオプションを使用します。
zypper rm package_name --clean-deps
Zypperではデフォルトで、選択したパッケージのインストールまたは削除の前に、あるいは問題が発生した際には、確認が求められます。この動作は、--non-interactiveオプションを使用することで上書きされます。このオプションは、次のように、実際のコマンド(install、remove、patch)の前に指定する必要があります。
zypper --non-interactive install package_nameこのオプションは、スクリプトおよびcronジョブでZypperを使用できます。
glibc、zypper、kernelなどのパッケージは削除しないでください。これらのパッケージはシステムで必須であり、削除するとシステムが不安定になったり、すべての動作が停止したりする場合があります。
パッケージの対応するソースパッケージをインストールする場合は、次を使用します。
zypper source-install package_name
このコマンドにより、指定したパッケージの構築依存もインストールされます。この処理が必要でない場合は、次のようにスイッチ-Dを追加します。ビルドの依存関係のみをインストールするには、-dを使用します。
zypper source-install -D package_name # source package only zypper source-install -d package_name # build dependencies only
もちろん、リポジトリリストで有効にしたソースパッケージを含むリポジトリが存在する場合にのみ動作します(ソースパッケージはデフォルトで追加されますが、有効にはなりません)。リポジトリの管理の詳細については、7.1.4項 「Zypperによるリポジトリの管理」を参照してください。
リポジトリで使用可能なすべてのソースパッケージのリストは、次のコマンドで参照できます。
zypper search -t srcpackage
また、すべてのインストール済みパッケージのソースパッケージをローカルディレクトリにダウンロードすることもできます。ソースパッケージをダウンロードするには、以下を使用します。
zypper source-download
デフォルトのダウンロードディレクトリは/var/cache/zypper/source-downloadです。これは、--directoryオプションを使って変更できます。ダウンロードや削除を行わず、不足パッケージや不要パッケージの表示のみを行う場合は、--statusオプションを使用します。不要なソースパッケージを削除するには、--deleteオプションを使用します。削除を無効にするには、--no-deleteオプションを使用します。
すべての依存関係が依然として満たされていることを確認し、欠如する依存関係を修復するには、次のコマンドを使用します。
zypper verify
必要とされる依存関係に加えて、一部のパッケージでは他のパッケージが「推奨されます」。これらの推奨対象パッケージは、実際に使用可能でインストール可能な場合のみインストールされます。推奨側のパッケージがインストールされた後で、(パッケージまたはハードウェアの追加により)推奨対象パッケージが使用可能になった場合は、次のコマンドを使用します。
zypper install-new-recommends
このコマンドは、WebcamまたはWi-Fiデバイスを接続した後で非常に役に立ちます。このコマンドは、デバイスのドライバと関連ソフトウェアが利用できる場合には、それらをインストールします。ドライバと関連ソフトウェアは、一定のハードウェア依存関係が満たされている場合のみインストールできます。
Zypperを使用してソフトウェアを更新するには3つの方法があります。パッチをインストールする、パッケージの新しいバージョンをインストールする、または配布全体を更新する方法です。最後の方法は、zypper dist-upgradeで行うことができます。SUSE Linux Enterprise Desktopのアップグレードについては、Chapter 4, Updating SUSE Linux Enterprise, Deployment Guideを参照してください。
正式にリリースされたすべてのパッチをインストールしてシステムに適用するには、次のコマンドを実行します。
zypper patch
この場合、リポジトリで利用可能なすべてのパッチが関連性についてチェックされ、必要に応じてインストールされます。インストールされたSUSE Linux Enterprise Desktopを登録すると、このようなパッチを含む公式なアップデートリポジトリがシステムに追加されます。上記のコマンドを入力すれば、いつでも必要なときにこれらを適用できます。
Zypperでは、パッチの可用性について問い合わせるための3つの異なるコマンドが認識されます。
zypper patch-check
必要なパッチの数を示します(システムに適用されていてもまだインストールされていないパッチ)。
tux > sudo zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)zypper list-patches
必要なすべてのパッチを示します(システムに適用されていてもまだインストールされていないパッチ)。
tux > sudo zypper list-patches
Loading repository data...
Reading installed packages...
Repository | Name | Version | Category | Status | Summary
---------------+-------------+---------+----------+---------+---------
SLES12-Updates | SUSE-2014-8 | 1 | security | needed | openssl: Update to OpenSSL 1.0.1g
zypper patches
インストール済みかどうかや、インストール環境に適用済みかどうかに関係なく、SUSE Linux Enterprise Desktopで使用可能なすべてのパッチを表示します。
また、特定の問題に関連するパッチを表示およびインストールすることもできます。特定のパッチを表示するには、次のオプションでzypper list-patchesコマンドを使用します。
--bugzilla[=number]
Bugzilla発信番号で必要なすべてのパッチを表示します。オプションとして、この特定のバグのパッチを一覧するだけの場合は、バグ番号を指定できます。
--cve[=番号]
CVE (Common Vulnerabilities and Exposures)問題に関して必要なすべてのパッチ、または特定のCVE番号に一致するパッチだけ(番号を指定した場合)を一覧します。
特定のBugzillaまたはCVEの問題に対するパッチをインストールするには、次のコマンドを使用します。
zypper patch --bugzilla=number
または
zypper patch --cve=number
たとえば、CVE番号がCVE-2010-2713のセキュリティパッチをインストールするには、次のコマンドを実行します。
zypper patch --cve=CVE-2010-2713
リポジトリに新しいパッケージのみが存在し、パッチが提供されていない場合は、zypper patchは無効です。インストールされているパッケージをすべて(システムの整合性を維持しながら)新しく入手可能なバージョンでアップデートするには、次を使用します。
zypper update
個別のパッケージをアップデートするには、updateコマンドまたはinstallコマンドのいずれかでパッケージを指定します。
zypper update package_name zypper install package_name
インストール可能なすべての新しいパッケージのリストを、次のコマンドで取得できます。
zypper list-updates
ただし、このコマンドで表示されるのは、次の条件に一致するパッケージのみです。
すでにインストール済みのパッケージと同じベンダである
すでにインストール済みのパッケージと同等以上の優先度をもつリポジトリによって提供される
インストール可能である(すべての依存関係が満たされている)
次のコマンドを使用すると、(インストール可能かどうかに関わらず)すべての新しい使用可能なパッケージのリストを取得できます。
zypper list-updates --all
新しいパッケージをインストールできない理由を見つけるには、上で説明されているように、zypper installコマンドまたはzypper updateコマンドを使用します。
Zypperのすべてのインストールまたはパッチのコマンドは、既知のリポジトリのリストに応じて異なります。システムで既知のすべてのリポジトリのリストを表示するには、次のコマンドを使用します。
zypper repos
結果は、次の出力のようになります。
# | Alias | Name | Enabled | Refresh --+--------------+---------------+---------+-------- 1 | SLEHA-12-GEO | SLEHA-12-GEO | Yes | No 2 | SLEHA-12 | SLEHA-12 | Yes | No 3 | SLES12 | SLES12 | Yes | No
各種コマンドのリポジトリを指定するには、エイリアス、URI、またはリポジトリ番号をzypper reposコマンド出力から使用できます。リポジトリの別名は、リポジトリ操作コマンド用の短いリポジトリ名です。ただし、リポジトリリストの変更後に、リポジトリ番号が変わる可能性があります。エイリアスは変更されることはありません。
デフォルトでは、URIやリポジトリの優先度など、詳細情報は表示されません。すべての詳細を表示するには、次のコマンドを使用します。
zypper repos -d
リポジトリを追加するには、次を実行します。
zypper addrepo URI alias
URIは、インターネットリポジトリ、ネットワークリソース、ディレクトリ、CDまたはDVDのいずれかです(詳細については、http://en.opensuse.org/openSUSE:Libzypp_URIsを参照してください)。別名は、リポジトリの短い固有のIDです。このIDは、固有である必要があること以外は自由に選択できます。すでに使用されているエイリアスを指定した場合、Zypperでは警告が発行されます。
リストからリポジトリを削除する場合は、コマンドzypper removerepoを使用し、削除するリポジトリのエイリアスまたは番号を指定します。たとえば、例7.1「Zypper—既知のリポジトリのリスト」からSLEHA-12-GEOリポジトリを削除するには、次のコマンドのいずれかを使用します。
zypper removerepo 1 zypper removerepo "SLEHA-12-GEO"
zypper modifyrepoによりリポジトリを有効または無効にします。また、このコマンドにより、リポジトリのプロパティ(動作、名前、優先度の更新など)を変更できます。次のコマンドは、updatesという名前のリポジトリを有効にし、自動更新をオンにし、リポジトリの優先度を 20に設定します。
zypper modifyrepo -er -p 20 'updates'
リポジトリを変更する場合、1つのリポジトリだけなく、リポジトリのグループも操作できます。
-a: すべてのリポジトリ |
-l: ローカルリポジトリ |
-t: リモートリポジトリ |
-m タイプ:特定のタイプのリポジトリ(ここで、タイプには、次のいずれかを指定できます: http、https、ftp、cd、dvd、dir、file、cifs、smb、nfs、hd、iso) 。 |
リポジトリエイリアスの名前を変更するには、renamerepoコマンドを使用します。次の例では、エイリアスをMozilla Firefoxからfirefoxに変更しています。
zypper renamerepo 'Mozilla Firefox' firefox
Zypperでは、リポジトリまたはパッケージをクエリするためのさまざまな方法が提供されています。使用可能なすべての製品、パターン、パッケージ、またはパッチのリストを取得するには、次のコマンドを使用します。
zypper products zypper patterns zypper packages zypper patches
特定のパッケージについてすべてのリポジトリをクエリするには、searchを使用します。searchは、パッケージの名前、またはパッケージの概要と説明(オプション)に関して機能します。/でラップされた文字列は、正規表現として解釈されます。デフォルトでは、検索で大文字と小文字は区別されません。
fireを含むパッケージ名の単純な検索
zypper search "fire"
MozillaFirefoxの単純な検索
zypper search --match-exact "MozillaFirefox"
zypper search -d fire
zypper search -u fire
firを含み、この後にeが続かないパッケージの表示
zypper se "/fir[^e]/"
特定の機能を提供するパッケージを検索するには、コマンドwhat-providesを使用します。たとえば、どのパッケージがPerlモジュールSVN::Coreを提供するか確認したい場合は、次のコマンドを使用します。
zypper what-provides 'perl(SVN::Core)'
単一のパッケージをクエリするには、infoを使用し、引数として正確なパッケージ名を指定します。パッケージに関する詳細情報を表示します。パッケージの要求や推奨も表示するには、--requiresオプションや--recommendsオプションを使用します。
zypper info --requires MozillaFirefox
what-providesパッケージはrpm -q --whatprovidesパッケージに似ていますが、RPMではRPMデータベース(つまり、すべてのインストール済みパッケージのデータベース)のみを問い合わせることができます。それに対してZypperは、インストール済みのパッケージだけでなく、すべてのリポジトリから機能のプロバイダに関する情報を表示します。
Zypperには、現在、設定ファイルが付属しています。この設定ファイルを使用すれば、Zypperの動作を(システム全体またはユーザ固有のでどちらかで)永続的に変更できます。システム全体に渡って変更する場合は、/etc/zypp/zypper.confを編集します。ユーザ固有に変更する場合は、~/.zypper.confを編集します。~/.zypper.confがまだ存在していない場合は、テンプレートとして/etc/zypp/zypper.confを使用できます。このテンプレートを~/.zypper.confにコピーして、好みに合わせて調整してください。利用できるオプションのヘルプについては、ファイル内のコメントを参照してください。
設定済みのリポジトリからのパッケージへのアクセスに問題がある場合(たとえば、一定のパッケージがリポジトリの1つに存在することを知っていても、Zypperでそのリポジトリを見つけられない場合など)は、次のコマンドでリポジトリを更新すると有効なことがあります。
zypper refresh
それも役に立たない場合は、次のコマンドを試してください。
zypper refresh -fdb
このコマンドは、生メタデータの強制ダウンロードを含むデータベースの完全な更新と再構築を強制します。
ルートパーティションでBtrfsファイルシステムが使用され、snapperがインストールされている場合に、ファイルシステムに対する変更をコミットして適切なファイルシステムスナップショットを作成すると、Zypperは(snapperによってインストールされるスクリプト経由で)自動的にsnapperを呼び出します。これらのスナップショットは、Zypperによって行われた変更を元に戻す場合に使用できます。詳細については、第4章 Snapperを使用したシステムの回復とスナップショット管理を参照してください。
コマンドラインからのソフトウェア管理の詳細については、「zypper help」、「zypper help command」と入力するか、zypper(8)のマニュアルページを参照してください。最も重要なコマンドの早見表を含む詳しいコマンドリファレンス、およびスクリプトやアプリケーションにおけるZypperの詳しい使い方については、http://en.opensuse.org/SDB:Zypper_usageを参照してください。SUSE Linux Enterprise Desktopの最新バージョンにおけるソフトウェアの変更点のリストについては、http://en.opensuse.org/openSUSE:Zypper versionsを参照してください。
RPM (RPM Package Manager)がソフトウェアパッケージを管理するのに使用されます。RPMの主要コマンドは、rpmとrpmbuildです。ユーザ、システム管理者、およびパッケージの作成者は、強力なRPMデータベースでクエリーを行って、インストールされているソフトウェアに関する情報を取得できます。
基本的にrpmには、ソフトウェアパッケージのインストール、アンインストール、アップデート、RPMデータベースの再構築、RPMベースまたは個別のRPMアーカイブの照会、パッケージの整合性チェック、およびパッケージへの署名の5種類のモードがあります。rpmbuildは、元のソースからインストール可能なパッケージを作成する場合に使用します。
インストール可能なRPMアーカイブは、特殊なバイナリ形式でパックされています。それらのアーカイブは、インストールするプログラムファイルとある種のメタ情報で構成されます。メタ情報は、ソフトウェアパッケージを設定するためにrpmによってインストール時に使用されるか、または文書化の目的でRPMデータベースに格納されています。通常、RPMアーカイブには拡張子.rpmが付けられます。
多くのパッケージにおいて、ソフトウェア開発に必要なコンポーネント(ライブラリ、ヘッダ、インクルードファイルなど)は、別々のパッケージに入れられています。それらの開発パッケージは、最新のGNOMEパッケージのように、ソフトウェアを自分自身でコンパイルする場合にのみ、必要になります。それらのパッケージは、名前の拡張子-deveで識別できます(alsa-develパッケージ、gimp-develパッケージなど)。
RPMパッケージにはGPG署名があります。RPMパッケージの署名を検証するには、rpm --checksig package-1.2.3.rpmコマンドを使用して、SUSEまたはその他の信頼できるツールから送信されたパッケージかどうか判別します。これは、インターネットからアップデートパッケージを入手する場合には、特に推奨されます。
通常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.」と入力します。解決されていない依存関係がない場合にパッケージのみを削除します。他のアプリケーションがTcl/Tkを必要とする限り、Tcl/Tkを削除することは理論的に不可能です。その場合でも、RPMはデータベースに援助を要求します。他の依存関係がない場合でも、また、どのような理由があってもそのような削除が不可能であれば、--rebuilddbオプションを使用してRPMデータベースを再構築するのがよいでしょう。
デルタRPMパッケージには、RPMパッケージの新旧バージョン間の違いが含まれています。デルタRPMを古いRPMに適用すると、まったく新しいRPMになります。デルタRPMは、インストールされているRPMとも互換性があるので、古いRPMのコピーを保管する必要はありません。デルタRPMパッケージは、パッチRPMよりもさらに小さく、パッケージをインターネット上で転送するのに便利です。欠点は、デルタRPMが組み込まれたアップデート操作の場合、そのままのRPMまたはパッチRPMに比べて、CPUサイクルの消費が目立って多くなることです。
prepdeltarpmおよびapplydeltaバイナリは、デルタRPMスイート(deltarpmパッケージ)の一部であり、デルタRPMパッケージの作成と適用に際して役立ちます。次のコマンドを使用して、new.delta.rpmというデルタRPMを作成できます。次のコマンドでは、old.rpmおよびnew.rpmが存在することが前提となります。
makedeltarpm old.rpm new.rpm new.delta.rpm
古いパッケージがすでにインストールされていれば、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を参照してください。
-qオプションを使用すると、rpmはクエリを開始し、(-pオプションを追加することにより)RPMアーカイブを検査できるようにして、インストールされたパッケージのRPMデータベースでクエリを行えるようにします。必要な情報の種類を指定する複数のスイッチを使用できます。詳細については、表7.1「最も重要なRPMクエリーのオプション」を参照してください。
|
|
パッケージ情報 |
|
|
ファイルリスト |
|
|
ファイルFILEを含むパッケージでクエリーを行います(FILEにはフルパスを指定する必要があります)。 |
|
|
ステータス情報を含むファイルリスト( |
|
|
ドキュメントファイルだけをリストします ( |
|
|
設定ファイルだけをリストします( |
|
|
詳細情報を含むファイルリスト( |
|
|
他のパッケージが |
|
|
パッケージが要求する機能 |
|
|
インストールスクリプト(preinstall、postinstall、uninstall) |
たとえば、コマンドrpm -q -i wgetは、例7.2「rpm -q -i wget」に示された情報を表示します。
Name : wget Relocations: (not relocatable) Version : 1.11.4 Vendor: openSUSE Release : 1.70 Build Date: Sat 01 Aug 2009 09:49:48 CEST Install Date: Thu 06 Aug 2009 14:53:24 CEST Build Host: build18 Group : Productivity/Networking/Web/Utilities Source RPM: wget-1.11.4-1.70.src.rpm Size : 1525431 License: GPL v3 or later Signature : RSA/8, Sat 01 Aug 2009 09:50:04 CEST, Key ID b88b2fd43dbdc284 Packager : http://bugs.opensuse.org URL : http://www.gnu.org/software/wget/ 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.8.0-4.3.x86_64 wget-1.11.4-11.18.x86_64
ファイル名の一部分しかわからない場合は、例7.3「パッケージを検索するスクリプト」に示すようなシェルスクリプトを使用します。実行するときに、ファイル名の一部を、パラメータとして示されるスクリプトに渡します。
#! /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 RPMpackageコマンドは、特定のパッケージに関する詳細な変更情報を日付順に表示します。
インストールされたRPMデータベースを使うと、確認検査を行うことができます。それらの検査は、-Vまたは--verifyオプションを使用して開始します。このオプションを使うと、rpmは、パッケージ内にあり、インストール以降変更されたことがあるすべてのファイルを表示します。rpmは、次の変更に関するヒントを表示するのに、8文字の記号を使用します。
|
|
MD5チェックサム |
|
|
ファイルサイズ |
|
|
シンボリックリンク |
|
|
変更時間 |
|
|
メジャーデバイス番号とマイナーデバイス番号 |
|
|
所有者 |
|
|
グループ |
|
|
モード (許可とファイルタイプ) |
設定ファイルの場合は、文字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です。
すべてのソースパッケージには、拡張子.src.rpm (ソース RPM)が付けられています。
ソースパッケージは、インストールメディアからハードディスクにコピーされ、YaSTを使用して展開できます。ただし、ソースパッケージは、パッケージマネージャでインストール済み([i])というマークは付きません。これは、ソースパッケージがRPMデータベースに入れられないためです。インストールされたオペレーティングシステムソフトウェアだけがRPMデータベースにリストされます。ソースパッケージを「インストールする」場合、ソースコードだけがシステムに追加されます。
(/etc/rpmrcなどのファイルでカスタム設定を指定していない限り)以下のディレクトリが、/usr/src/packagesの下でrpmとrpmbuildから使用可能でなければなりません。
YaSTでソースパッケージをインストールすると、必要なコンポーネントがすべて/usr/src/packagesにインストールされます。 SOURCES内のソースおよび調整ファイルとSPECS内の関連.specファイルです。
システムコンポーネント(glibc、rpmなど)で実験を行わないでください。システムが正しく動作しなくなります。
次の例は、wget.src.rpmパッケージを使用します。ソースパッケージをインストールすると、次のようなファイルが生成されます。
/usr/src/packages/SOURCES/wget-1.11.4.tar.bz2 /usr/src/packages/SOURCES/wgetrc.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コマンドでインストールできます。 -Urpmを使用したインストールは、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コマンドで、詳細な情報が得られます。
Midnight Commander (mc)は、RPMアーカイブの内容を表示し、それらの一部をコピーできます。アーカイブを仮想ファイルシステムとして表し、Midnight Commanderの通常のメニューオプションを使用できます。<F3>キーを使用してHEADERを表示します。カーソルキーと<Enter>キーを使ってアーカイブ構造を表示します。F5キーを使用してアーカイブコンポーネントをコピーします。
フル機能のパッケージマネージャをYaSTモジュールとして使用できます詳細については、Chapter 6, Installing or Removing Software, Deployment Guideを参照してください。