第5章 コマンドラインツールによるソフトウェアの管理

目次

5.1. Zypperの使用
5.2. RPM—パッケージマネージャ

概要

この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される述語(たとえば、repositorypatchupdateなど)の定義については、「用語の定義」 (第9章 ソフトウェアをインストールまたは削除する, ↑導入ガイド)を参照してください。

5.1. Zypperの使用

Zypperは、パッケージのインストール、更新、削除、およびリポジトリの管理を行うためのコマンドラインパッケージマネージャです。zypperの構文はrugに類似しています。rugとは対照的に、zypperではzmdデーモンが背後で実行している必要はありません。rugの互換性の詳細は、man zypperCOMPATIBILITY WITH RUGの項を参照してください。 これは特に、リモートソフトウェア管理タスクの実行、またはシェルスクリプトからのソフトウェアの管理で役立ちます。

5.1.1. 一般的な使用方法

Zypperの一般的な構文は次のとおりです。

zypper [global-options]command[command-options][arguments] ...

ブラケットで囲まれたコンポーネントは必須ではありません。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リポジトリからmplayeramarokパッケージをインストールします。

zypper -v install --from factory mplayer amarok

--fromオプションは、指定されたリポジトリからパッケージを要求する際に、すべてのリポジトリを(依存関係の解決のため)有効に保ちます。

ほとんどのZypperコマンドには、指定のコマンドのシミュレーションを行うdry-runオプションがあります。このオプションは、テストの目的で使用できます。

zypper remove --dry-run MozillaFirefox

5.1.2. Zypperを使ったソフトウェアのインストールと削除

パッケージをインストールまたは削除するには、次のコマンドを使用します。

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 'perl(Time::ParseDate)'
機能、アーキテクチャ、および(または)バージョンを指定します

機能とともに、アーキテクチャ(i586またはx86_64など)、および(または)バージョンを指定できます。バージョンの前には、演算子として、<(未満)、<=(以下)、=(等しい)、=>(以上)、または>(より大きい)を付ける必要があります:

zypper install 'firefox.x86_64'
zypper install 'firefox>=3.5.3'
zypper install 'firefox.x86_64>=3.5.3'
RPMファイルへのパスによって指定します

また、パッケージに対するローカルパスまたはリモートパスを指定できます。

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オプションを使用します。

rm package_name --clean-deps

Zypperではデフォルトで、選択したパッケージのインストールまたは削除の前に、あるいは問題が発生した際には、確認が求められます。この動作は、--non-interactiveオプションを使用することで上書きされます。このオプションは、次のように、実際のコマンド(installremovepatch)の前に指定する必要があります。

zypper --non-interactive install package_name

このオプションは、スクリプトおよびcronジョブでZypperを使用できます。

[Warning]必須システムパッケージは削除しないでください。

glibczypperkernelなどのパッケージは削除しないでください。これらのパッケージはシステムで必須であり、削除するとシステムが不安定になったり、すべての動作が停止したりする場合があります。

5.1.2.1. ソースパッケージのインストール

パッケージの対応するソースパッケージをインストールする場合は、次を使用します。

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

もちろん、リポジトリリストで有効にしたソースパッケージを含むリポジトリが存在する場合にのみ動作します(ソースパッケージはデフォルトで追加されますが、有効にはなりません)。リポジトリの管理の詳細については、5.1.5項 「Zypperによるリポジトリの管理」を参照してください。

リポジトリで使用可能なすべてのソースパッケージのリストは、次のコマンドで参照できます。

zypper search -t srcpackage

5.1.2.2. ユーティリティ

すべての依存関係が依然として満たされていることを確認し、欠如する依存関係を修復するには、次のコマンドを使用します。

zypper verify

必要とされる依存関係に加えて、一部のパッケージでは他のパッケージが推奨されます。これらの推奨対象パッケージは、実際に使用可能でインストール可能な場合のみインストールされます。推奨側のパッケージがインストールされた後で、(パッケージまたはハードウェアの追加により)推奨対象パッケージが使用可能になった場合は、次のコマンドを使用します。

zypper install-new-recommends

このコマンドは、WebcamまたはWLANデバイスにプラグインした後で非常に役に立ちます。このコマンドは、デバイスのドライバと関連ソフトウェアが利用できる場合には、それらをインストールします。ドライバと関連ソフトウェアは、一定のハードウェア依存関係が満たされている場合のみインストールできます。

5.1.3. Zypperによるソフトウェアの更新

Zypperを使用してソフトウェアを更新するには3つの方法があります。パッチをインストールする、パッケージの新しいバージョンをインストールする、または配布全体を更新する方法です。最後の方法は、5.1.4項 「zypperによるディストリビューションアップグレード」で説明されているzypper dist-upgradeコマンドで行うことができます。

5.1.3.1. パッチのインストール

正式にリリースされたすべてのパッチをインストールしてシステムに適用するには、次のコマンドを実行するだけです。

zypper patch

この場合、リポジトリで利用可能なすべてのパッチが関連性についてチェックされ、必要に応じてインストールされます。SUSE Linux Enterprise Serverインストールを登録した後、このようなパッチを含む正式な更新リポジトリがシステムに追加されます。上記のコマンドを入力すれば、いつでも必要なときにこれらを適用できます。

Zypperでは、パッチの可用性について問い合わせるための3つの異なるコマンドが認識されます。

zypper patch-check

必要なパッチの数を示します(システムに適用されていてもまだインストールされていないパッチ)。

~ # zypper patch-check
Loading repository data...
Reading installed packages...
5 patches needed (1 security patch)
zypper list-patches

必要なすべてのパッチを示します(システムに適用されていてもまだインストールされていないパッチ)。


~ # zypper list-patches
Loading repository data...
Reading installed packages...
 
Repository                          | Name      | Version | Category | Status
------------------------------------+-----------+---------+----------+-------
Updates for openSUSE 11.3 11.3-1.82 | lxsession | 2776    | security | needed
zypper patches

すでにインストールされているか、インストールに適用されているかどうかにかかわらず、SUSE Linux Enterprise Serverで使用可能なすべてのパッチを表示します。

また、特定の問題に関連するパッチを表示およびインストールすることもできます。特定のパッチを表示するには、次のオプションで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

5.1.3.2. 更新のインストール

リポジトリに新しいパッケージのみが存在し、パッチが提供されていない場合は、zypper patchは無効です。インストールされているパッケージをすべて新しく入手可能なバージョンで更新するには、次を使用します。

zypper update

個別のパッケージを更新するには、更新コマンドまたはインストールコマンドのいずれかでパッケージを指定します。

zypper update package_name
zypper install package_name

インストール可能なすべての新しいパッケージのリストを、次のコマンドで取得できます。

zypper list-updates

ただし、このコマンドは、次の基準と一致するパッケージのみ一覧します。

  • すでにインストール済みのパッケージと同じベンダである

  • すでにインストール済みのパッケージと同等以上の優先度をもつリポジトリによって提供される

  • インストール可能である(すべての依存関係が満たされている)

次のコマンドを使用すると、(インストール可能かどうかに関わらず)すべての新しい使用可能なパッケージのリストを取得できます。

zypper list-updates --all

新しいパッケージをインストールできない理由を見つけるには、上記で説明されているように、zypper installコマンドまたはzypper updateコマンドを使用します。

5.1.3.3. 新しい製品バージョンへのアップグレード

インストールを新しい製品バージョンに簡単にアップグレードするには(たとえば、SUSE Linux Enterprise Server 11からSUSE Linux Enterprise Server 11 SP1へのアップグレード)、まず、現在のSUSE Linux Enterprise Serverリポジトリに一致するようにリポジトリを調整します。詳細については、5.1.5項 「Zypperによるリポジトリの管理」を参照してください。次に、必要なリポジトリに関してzypper dist-upgradeコマンドを使用します。このコマンドにより、現在有効なリポジトリからすべてのパッケージがインストールされます。詳細の説明については、5.1.4項 「zypperによるディストリビューションアップグレード」を参照してください。

ディストリビューションアップグレードを特定のリポジトリのパッケージに制限しながら、他のリポジトリも考慮に入れて依存関係を満たすには、--fromオプションを使用して、リポジトリをその別名、番号、またはURIで指定します。

[Note]zypper updatezypper dist-upgradeの相違

システムの整合性を維持しながら製品のバージョンで使用可能な新しいバージョンにパッケージを更新する場合は、zypper updateを選択します。zypper updateは、次のルールに従います。

ベンダは変更されません
アーキテクチャは変更されません
ダウングレードされません
インストール済みパッケージが保持されます

zypper dist-upgradeを実行すると、すべてのパッケージが現在有効なリポジトリからインストールされます。このルールを適用した場合、パッケージによりベンダまたはアーキテクチャが変更されるか、ダウングレードされる場合もあります。アップグレード後に依存関係が満たされていないすべてのパッケージはアンインストールされます。

5.1.4. zypperによるディストリビューションアップグレード

zypperコマンドラインユーティリティを使用すると、次のバージョンのディストリビューションにアップグレードできます。最も重要なことは、実行中のシステムからシステムアップグレードのプロセスを開始できることです。

これは、リモートアップグレードや、同様な設定の多数のシステムでアップグレードを実行したい高度なユーザにとって魅力的な機能です。

5.1.4.1. zypperによるアップグレードを開始する前に

zypperを使用したアップグレード中に予期しないエラーが発生しないようにするには、リスクの高いコンステレーションを最小限にします。

できるだけ多くのアプリケーションや不要なサービスを終了し、すべての通常ユーザをログアウトします。

アップグレードの開始前にサードパーティーのリポジトリを無効にしたり、それらのリポジトリの優先度を下げることによって、デフォルトのシステムリポジトリからのパッケージが優先されるようにします。アップグレード後にそれらのリポジトリを再度有効にし、それらのバージョン文字列を編集して、アップグレードした現在実行中のシステムのディストリビューションのバージョン番号に一致させます。

5.1.4.2. アップグレード手順

[Warning]システムのバックアップを確認してください。

アップグレード手順を実際に開始する前に、システムのバックアップが最新であり、復元可能であることを確認します。以降のステップの多くで手動入力が必要なので、これは特に重要です。

  1. オンラインアップデートを実行して、ソフトウェア管理スタックを最新にします。詳細については、第1章 YaSTオンラインアップデートを参照してください。

  2. 更新のソースとして使用するリポジトリを設定します。これを正しく設定することは非常に重要です。YaST(「ソフトウェアリポジトリおよびサービスの操作」 (第9章 ソフトウェアをインストールまたは削除する, ↑導入ガイド)参照)またはzypper(5.1項 「Zypperの使用」参照)のいずれかを使用します。以降のステップで使用するリポジトリの名前は、カスタマイズの仕方によって若干異なることがあります。

    独自のインストールサーバを準備または更新するとします。背景情報については、「YaSTを使ったインストールサーバのセットアップ」 (第14章 リモートインストール, ↑導入ガイド)を参照してください。

    現在のリポジトリを表示するには、次のコマンドを入力します。

    zypper lr -u
    
    [Tip]zypperコマンド名

    zypperは、長いコマンド名と短いコマンド名をサポートしています。たとえば、zypper installを短縮してzypper inにすることができます。次のテキストでは、短いコマンド名が使用されています。

    1. 次のようなコマンドで、システムリポジトリのバージョン番号を11から11-SP1に増やし、新しい11_SP1リポジトリを追加します。

      server=http://download.example.org
      zypper ar $server/distribution/11-SP1/repo/oss/ SLE-11-SP1
      zypper ar $server/update/11-SP1/ SLE-11-SP1-Update
      

      次に、古いリポジトリを削除します。

      zypper rr SLE-11
      zypper rr SLE-11-Update
    2. サードパーティのリポジトリまたは他のOpen Build Serviceリポジトリを無効にします。これは、zypper dupがデフォルトリポジトリのみを操作するように保証するためです。(replace repo-aliasを、無効にしたいリポジトリの名前で置き換えます):

      zypper mr -d repo-alias

      または、これらのリポジトリの優先順位を下げることもできます。

      [Note]未解決の依存関係の処理

      zypper dupは、未解決の依存関係を持つすべてのパッケージを削除します。ただし、無効化されたリポジトリのパッケージについては、それらの依存関係が正常である限り、それらを保持します。

      zypper dupを使用すると、すべてのインストール済みパッケージは利用可能なリポジトリの1つをソースとします。zypper dupは、インストールパッケージのバージョン、アーキテクチャ、ベンダを考慮に入れず、フレッシュインストールをエミュレートします。リポジトリ内で利用可能でなくなったパッケージは、孤立したと見なされます。そのようなパッケージは、その依存関係が正常でなければ、アンインストールされます。依存関係が正常な場合は、そのようなパッケージのインストールは保持されます。

    3. これらの処理が終了したら、次のコマンドでリポジトリの設定を確認します。

      zypper lr -d
      
  3. ローカルメタデータとリポジトの内容を、zypper refで更新します。

  4. zypper up zypperを使用して、zyppeとパッケージ管理スタックを11 SP1リポジトリから取り込みます。

  5. zypper dupで、実際のディストリビューションアップグレードを実行します。SUSE Linux Enterpriseのライセンスと一部のパッケージ(インストール済みパッケージのセットによって異なる)のライセンスの確認を要求されます。

  6. SuSEconfigで、基本的なシステム設定を実行します。

  7. shutdown -r nowで、システムをリブートします。

5.1.5. Zypperによるリポジトリの管理

Zypperのすべてのインストールまたはパッチのコマンドは、既知のリポジトリのリストに応じて異なります。システムで既知のすべてのリポジトリのリストを表示するには、次のコマンドを使用します。

zypper repos

結果は、次の出力のようになります。

例5.1 Zypper—既知のリポジトリのリスト



# | Alias                             | Name                              | Enabled | Refresh
--+-----------------------------------+-----------------------------------+---------+--------
1 | SUSE-Linux-Enterprise-Server 11-0 | SUSE-Linux-Enterprise-Server 11-0 | Yes     | No
2 | SLES-11-Updates                   | SLES 11 Online Updates            | Yes     | Yes
3 | broadcomdrv                       | Broadcom Drivers                  | Yes     | No      

各種コマンドのリポジトリを指定するには、エイリアス、URI、またはリポジトリ番号をzypper reposコマンド出力から使用できます。リポジトリの別名は、リポジトリ操作コマンド用の短いリポジトリ名です。ただし、リポジトリリストの変更後に、リポジトリ番号が変わる可能性があります。エイリアスは変更されることはありません。

デフォルトでは、URIやリポジトリの優先度など、詳細情報は表示されません。すべての詳細を表示するには、次のコマンドを使用します。

zypper repos -d

5.1.5.1. リポジトリの追加

リポジトリを追加するには、次を実行します。

zypper addrepo URIalias

URIは、インターネットリポジトリ、ネットワークリソース、ディレクトリ、CDまたはDVDのいずれかです(詳細については、http://en.opensuse.org/openSUSE:Libzypp_URIsを参照してください)。別名は、リポジトリの短い固有のIDです。このIDは、固有であること以外は自由に選択できます。すでに使用されているエイリアスを指定した場合、Zypperでは警告が発行されます。

5.1.5.2. リポジトリの削除

リストからリポジトリを削除する場合は、コマンドzypper removerepoを使用し、削除するリポジトリのエイリアスまたは番号を指定します。たとえば例5.1「Zypper—既知のリポジトリのリスト」の3番目のエントリとして表示されているリポジトリを削除するには、次のコマンドを使用します。

zypper removerepo 3

5.1.5.3. リポジトリの変更

zypper modifyrepoによりリポジトリを有効または無効にします。また、このコマンドにより、リポジトリのプロパティ(動作、名前、優先度の更新など)を変更できます。次のコマンドは、updatesという名前のリポジトリを有効にし、自動更新をオンにし、リポジトリの優先度を 20に設定します。

zypper modifyrepo -er -p 20 'updates'

リポジトリの変更は、単一のリポジトリに制限されません。リポジトリグループを操作することもできます。

-a: すべてのリポジトリ
-l: ローカルリポジトリ
-t: リモートリポジトリ
-m タイプ:特定のタイプのリポジトリ(ここで、タイプには、次のいずれかを指定できます: httphttpsftpcddvddirfilecifssmbnfshdiso) 。

リポジトリエイリアスの名前を変更するには、renamerepoコマンドを使用します。次の例では、エイリアスをMozilla Firefoxから単なるfirefoxに変更しています。

zypper renamerepo 'Mozilla Firefox' firefox

5.1.6. Zypperによるリポジトリおよびパッケージのクエリ

Zypperでは、リポジトリまたはパッケージをクエリするためのさまざまな方法が提供されています。使用可能なすべての製品、パターン、パッケージ、またはパッチのリストを取得するには、次のコマンドを使用します。

zypper products
zypper patterns
zypper packages
zypper patches

特定のパッケージについてすべてのリポジトリをクエリするには、searchを使用します。searchは、パッケージの名前、またはパッケージの概要と説明(オプション)に関して機能します。検索語では、ワイルドカード*および?を使用できます。デフォルトでは、検索で大文字と小文字が区別されません。

zypper search firefox       # simple search for "firefox"
zypper search "*fire*"      # using wildcards
zypper search -d fire       # also search in package descriptions and summaries
zypper search -u firefox    # only display packages not already installed

特定の機能を提供するパッケージを検索するには、コマンド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は、インストール済みのパッケージだけでなく、すべてのリポジトリから機能プロバイダに関する情報を表示します。

5.1.7. Zypperの設定

Zypperには、現在、設定ファイルが付属しています。この設定ファイルを使用すれば、Zypperの動作を(システム全体またはユーザ固有のでどちらかで)永続的に変更できます。システム全体に渡って変更する場合は、/etc/zypp/zypper.confを編集します。ユーザ固有に変更する場合は、~/.zypper.confを編集します。~/.zypper.confがまだ存在していない場合は、テンプレートとして/etc/zypp/zypper.confを使用できます。このテンプレートを~/.zypper.confにコピーして、好みに合わせて調整してください。利用できるオプションのヘルプについては、ファイル内のコメントを参照してください。

5.1.8. トラブルシューティング

設定済みのリポジトリからのパッケージへのアクセスに問題がある場合(たとえば、一定のパッケージがリポジトリの1つに存在することを知っていても、zypperでそのリポジトリを見つけられない場合など)は、次のコマンドでリポジトリを更新すると有効なことがあります。

zypper refresh

それも役に立たない場合は、次のコマンドを試してください。

zypper refresh -fdb

このコマンドは、生メタデータの強制ダウンロードを含むデータベースの完全な更新と再構築を強制します。

5.1.9. btrfsファイルシステムでのZypperロールバック機能

btrfsファイルシステムがルートパーティションで使用されている場合、zypperは、変更をファイルシステムにコミットする際に、自動的にsnapperを呼び出して、適切なファイルシステムのスナップショットを作成します。これらのスナップショットは、zypperによって行われた変更を元に戻す場合に使用できます。snapperの詳細については、man snapperを参照してください。

この機能は、デフォルトファイルシステムではサポートされていません。

5.2. RPM—パッケージマネージャ

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

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

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

[Tip]ソフトウェア開発パッケージ

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

5.2.1. パッケージの信頼性の検証

RPMパッケージにはGnuPG署名があります。RPMパッケージの署名を検証するには、rpm --checksig パッケージ-1.2.3.rpmコマンドを使用して、Novell/SUSEまたはその他の信頼できるツールから送信されたパッケージかどうか判別します。これは、インターネットからアップデートパッケージを入手する場合には、特に推奨されます。

5.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データベースを再構築するのがよいでしょう。

5.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コマンドのマニュアルページで収集できます。

[Note]SUSE Linux Enterprise Serverの公式アップデート

アップデートのダウンロードサイズをできる限り小さくするため、SUSE Linux Enterprise Serverの公式アップデートはパッチRPMとしてではなく、デルタRPMパッケージとして提供されます。詳細については、5.2.4項 「デルタRPMパッケージ」を参照してください。

5.2.4. デルタRPMパッケージ

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

prepdeltarpmwritedeltarpm、および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.cpionew.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を参照してください。

5.2.5. RPMクエリー

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

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

-i

パッケージ情報

-l

ファイルリスト

-f FILE

ファイルFILEを含むパッケージでクエリーを行います(FILEにはフルパスを指定する必要があります)。

-s

ステータス情報を含むファイルリスト(-lを暗示指定)

-d

ドキュメントファイルだけをリストします (-lを暗示指定)。

-c

設定ファイルだけをリストします(-lを暗示指定)。

--dump

詳細情報を含むファイルリスト(-l-c、または-d と共に使用します)

--provides

他のパッケージが--requiresで要求できるパッケージの機能をリストします。

--requires, -R

パッケージが要求する機能

--scripts

インストールスクリプト(preinstall、postinstall、uninstall)


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

例5.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

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

例5.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 rpm コマンドは、特定のパッケージ (この場合はrpmパッケージ)に関する詳細な変更情報を日付順に一覧しますの詳細なリストを表示します。

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

表5.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です。

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

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

[Note]インストール済みのソースパッケージ

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

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

SOURCES

オリジナルのソース(.tar.gzファイルや.tar.gzファイルなど)とディストリビューション固有の調整ファイル(ほとんどの場合.difファイルや.patchファイル)用です。

SPECS

ビルド処理 を制御する、メタMakefileに類似した.specファイル用です。

BUILD

すべてのソースは、このディレクトリでアンパック、パッチ、およびコンパイルされます。

RPMS

完成したバイナリパッケージが格納されます。

SRPMS

ソースRPMが格納されます。

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

[Warning]

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

次の例は、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 -Uコマンドでインストールできます。rpmを使用したインストールは、RPMデータベースに登場します。

5.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コマンドで、詳細な情報が得られます。

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

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

フル機能のパッケージマネージャをYaSTモジュールとして使用できます詳細については、第9章 ソフトウェアをインストールまたは削除する (↑導入ガイド)を参照してください。