9 コマンドラインツールによるソフトウェアの管理 #
この章では、ソフトウェア管理の2つのコマンドラインツールとして、ZypperとRPMについて説明します。このコンテキストで使用される用語(repository
、patch
、update
など)の定義については、8.1項 「用語の定義」を参照してください。
9.1 Zypperの使用 #
Zypperは、パッケージのインストール、更新、および削除を行うためのコマンドラインパッケージマネージャです。リポジトリの管理も行います。これは特に、リモートソフトウェア管理タスクの実行、またはシェルスクリプトからのソフトウェアの管理で役立ちます。
9.1.1 一般的な使用方法 #
Zypperの一般的な構文は次のとおりです。
zypper[--global-options]
COMMAND[--command-options]
[arguments]
ブラケットで囲まれたコンポーネントは必須ではありません。一般的なオプションおよびすべてのコマンドのリストについては、zypper
help
を参照してください。特定のコマンドのヘルプを参照するには、「zypper help
COMMAND」と入力します。
- Zypperのコマンド
Zypperを実行する最も簡単な方法は、その名前の後にコマンドを入力することです。たとえば、システムに必要なすべてのパッチを適用するには、次のコマンドを使用します。
>
sudo
zypper patch- グローバルオプション
さらに、グローバルオプションをコマンドの直前に入力することによって、1つ以上のグローバルオプションを選択することもできます。
>
sudo
zypper --non-interactive patch上の例では、オプション
--non-interactive
は、確認を一切表示せずにコマンドを実行することを意味します(自動的にデフォルトの回答を適用します)。- コマンド固有のオプション
特定のコマンドに固有のオプションを使用する場合は、コマンドの直後にそのオプションを入力します。
>
sudo
zypper patch --auto-agree-with-licenses上の例では、
--auto-agree-with-licenses
を使用して、ライセンスの確認を表示せずに、必要なすべてのパッチをシステムに適用します。その代わりに、自動的にライセンスに同意します。- 引数
一部のコマンドでは、1つ以上の引数が必要です。たとえば、コマンド
install
を使用する場合、「インストール」するパッケージを1つまたは複数指定する必要があります。>
sudo
zypper install mplayer一部のオプションでは、1つの引数が必要です。次のコマンドでは、すべての既知のパターンが表示されます。
>
zypper search -t pattern
上記のすべてを結合できます。たとえば、次のコマンドは、冗長モードで、factory
リポジトリからmcとvimパッケージをインストールします。
>
sudo
zypper -v install --from factory mc vim
--from
オプションは、指定されたリポジトリからパッケージを要求する際に、すべてのリポジトリを(依存関係の解決のため)有効に保ちます。--repo
は、--from
のエイリアスで、いずれかのものを使用できます。
ほとんどのZypperコマンドには、指定のコマンドのシミュレーションを行うdry-run
オプションがあります。このオプションは、テストの目的で使用できます。
>
sudo
zypper remove --dry-run MozillaFirefox
Zypperは、グローバルオプション--userdata
STRING
をサポートします。このオプションを使用して文字列を指定することができます。指定した文字列は、Zypperのログファイルとプラグイン(Btrfsプラグインなど)に書き込まれます。これを使用して、ログファイルでトランザクションにマークを付けたり、トランザクションを特定したりできます。
>
sudo
zypper --userdata STRING patch
9.1.2 Zypperサブコマンドの使用 #
Zypperサブコマンドは、zypper_execdir
設定オプションで指定されたディレクトリに保存される実行可能ファイルです。デフォルトでは/usr/lib/zypper/commands
です。サブコマンドがそこで見つからない場合、Zypperはその$PATHの残りの部分を自動的に検索します。これにより、独自のローカル拡張機能を作成し、ユーザスペースに保存することができます。
Zypperシェルでのサブコマンドの実行、グローバルZypperオプションの使用はサポートされていません。
使用可能なサブコマンドの一覧表示:
>
zypper help subcommand
[...]
Available zypper subcommands in '/usr/lib/zypper/commands'
appstream-cache
lifecycle
migration
search-packages
Zypper subcommands available from elsewhere on your $PATH
log Zypper logfile reader
(/usr/sbin/zypper-log)
サブコマンドのヘルプ画面の表示
>
zypper help appstream-cache
9.1.3 Zypperを使ったソフトウェアのインストールと削除 #
パッケージをインストールまたは削除するには、次のコマンドを使用します。
>
sudo
zypper install PACKAGE_NAME>
sudo
zypper remove PACKAGE_NAME
glibc、zypper、kernelなどの必須システムパッケージは削除しないでください。これらを削除すると、システムが不安定になったり、まったく動作しなくなったりする可能性があります。
9.1.3.1 インストールまたは削除するパッケージの選択 #
コマンドzypper install
およびzypper remove
でパッケージを指定するには、さまざまな方法があります。
- 正確なパッケージ名を指定する
>
sudo
zypper install MozillaFirefox- 正確なパッケージ名とバージョン番号を指定する
>
sudo
zypper install MozillaFirefox-52.2- リポジトリエイリアスとパッケージ名を指定する
>
sudo
zypper install mozilla:MozillaFirefoxここで
mozilla
は、インストールするリポジトリのエイリアスです。- ワイルドカードを使用してパッケージ名を指定する
名前が特定の文字列で始まるか、特定の文字列で終わるパッケージをすべて選択できます。特にパッケージを削除する場合は、ワイルドカードの使用には注意が必要です。次のコマンドでは、名前の先頭に「Moz」が付くすべてのパッケージがインストールされます。
>
sudo
zypper install 'Moz*'ヒント: すべての-debuginfo
パッケージを削除問題をデバッグする際、実行中のプロセスに関する情報を多く得るために、一時的に多数の
-debuginfo
パッケージをインストールする場合があります。デバッグセッションが終了したら、この環境を消去する必要があります。それには以下を実行します。>
sudo
zypper remove '*-debuginfo'- 機能によって指定する
たとえば、名前がわからないパッケージをインストールする場合は、機能による指定が便利です。次のコマンドは、パッケージMozillaFirefoxをインストールします。
>
sudo
zypper install firefox- 機能、ハードウェアアーキテクチャ、またはバージョンによって指定する
機能とともに、ハードウェアアーキテクチャとバージョンを指定できます。
機能の後にピリオドを付けて、その後に目的のハードウェアアーキテクチャの名前を追加します。たとえば、AMD/Intel 64アーキテクチャ(Zypperでの名前は
x86_64
_64)を指定するには、次のコマンドを使用します。>
sudo
zypper install 'firefox.x86_64'バージョンは文字列の最後に追加し、バージョンの前に演算子を付ける必要があります。使用できる演算子は、
<
(より小さい)、<=
(以下)、=
(等しい)、>=
(以上)、>
(より大きい)です。>
sudo
zypper install 'firefox>=74.2'必要なハードウェアアーキテクチャとバージョンを組み合わせて指定することもできます。
>
sudo
zypper install 'firefox.x86_64>=74.2'
- RPMファイルのパスによって指定する
また、パッケージに対するローカルパスまたはリモートパスを指定できます。
>
sudo
zypper install /tmp/install/MozillaFirefox.rpm>
sudo
zypper install http://download.example.com/MozillaFirefox.rpm
9.1.3.2 パッケージのインストールと削除の結合 #
パッケージのインストールと削除を同時に行うには、+/-
修飾子を使用します。emacsをインストールし、同時にvimを削除するには、次のコマンドを使用します。
>
sudo
zypper install emacs -vim
emacsを削除し、同時にvimをインストールするには、次のコマンドを使用します。
>
sudo
zypper remove emacs +vim
名前の先頭に-
が付くパッケージ名がコマンドオプションとして解釈されないようにするには、常に第2引数としてその名前を使用します。これが可能でない場合は、名前の前に--
を付けます。
>
sudo
zypper install -emacs +vim # Wrong>
sudo
zypper install vim -emacs # Correct>
sudo
zypper install -- -emacs +vim # Correct>
sudo
zypper remove emacs +vim # Correct
9.1.3.3 削除されたパッケージの依存関係のクリーンアップ #
指定したパッケージの削除後に、不要になったパッケージも自動的に削除されるようにしたい場合は、--clean-deps
オプションを使用します。
>
sudo
zypper rm --clean-deps PACKAGE_NAME
9.1.3.4 スクリプトでのZypperの使用 #
Zypperではデフォルトで、選択したパッケージのインストールまたは削除の前に、あるいは問題が発生した際には、確認が求められます。この動作は、--non-interactive
オプションを使用することで上書きされます。このオプションは、次のように、実際のコマンド(install
、remove
、patch
)の前に指定する必要があります。
>
sudo
zypper--non-interactive
install PACKAGE_NAME
このオプションは、スクリプトおよびcronジョブでZypperを使用できます。
9.1.3.5 ソースパッケージのインストールまたはダウンロード #
パッケージの対応するソースパッケージをインストールするには、次のコマンドを使用します。
>
zypper source-install PACKAGE_NAME
ソースパッケージをインストールするデフォルトの場所は、root
として実行する場合は/usr/src/packages/
、ユーザとして実行する場合は~/rpmbuild
になります。これらの値はローカルのrpm
設定で変更できます。
このコマンドにより、指定したパッケージのビルド依存関係もインストールされます。この処理が必要でない場合は、次のようにスイッチ-D
を追加します。
>
sudo
zypper source-install -D PACKAGE_NAME
ビルドの依存関係のみをインストールするには、-d
を使用します。
>
sudo
zypper source-install -d PACKAGE_NAME
もちろん、リポジトリリストで有効にしたソースパッケージを含むリポジトリが存在する場合にのみ動作します(ソースパッケージはデフォルトで追加されますが、有効にはなりません)。リポジトリの管理の詳細については、9.1.6項 「Zypperによるリポジトリの管理」を参照してください。
リポジトリで使用可能なすべてのソースパッケージのリストは、次のコマンドで参照できます。
>
zypper search -t srcpackage
また、すべてのインストール済みパッケージのソースパッケージをローカルディレクトリにダウンロードすることもできます。ソースパッケージをダウンロードするには、以下を使用します。
>
zypper source-download
デフォルトのダウンロードディレクトリは/var/cache/zypper/source-download
です。これは、--directory
オプションを使って変更できます。ダウンロードや削除を行わず、不足パッケージや不要パッケージの表示のみを行う場合は、--status
オプションを使用します。不要なソースパッケージを削除するには、--delete
オプションを使用します。削除を無効にするには、--no-delete
オプションを使用します。
9.1.3.6 無効にされたリポジトリからのパッケージのインストール #
通常、パッケージのインストールや更新は、有効化されたリポジトリからしかできません。--plus-content
TAG
オプションを使用すると、リポジトリをリフレッシュし、現在のZypperセッション中のみ一時的に有効にして、終了したら無効にすることができます。
たとえば、追加の-debuginfo
パッケージまたは-debugsource
パッケージを提供するリポジトリを有効にするには、--plus-content debug
を使用します。このオプションは複数回指定できます。
そうした「デバッグ」リポジトリを一時的に有効にして、特定の-debuginfo
パッケージをインストールするには、次のオプションを使用します。
>
sudo
zypper --plus-content debug \ install "debuginfo(build-id)=eb844a5c20c70a59fc693cd1061f851fb7d046f4"
debuginfoパッケージがないと、build-id
文字列が、gdb
によって報告されます。
SUSE Linux Enterprise Serverインストールメディアのリポジトリは引き続き設定されていますが、インストールが正常に完了すると無効になります。--plus-content
オプションを使用して、オンラインリポジトリの代わりにインストールメディアからパッケージをインストールできます。zypper
を呼び出す前に、DVDをコンピュータのドライブに挿入するなどして、メディアが使用可能であることを確認してください。
9.1.3.7 ユーティリティ #
すべての依存関係が依然として満たされていることを確認し、欠如する依存関係を修復するには、次のコマンドを使用します。
>
zypper verify
必要とされる依存関係に加えて、一部のパッケージでは他のパッケージが「推奨されます」。これらの推奨対象パッケージは、実際に使用可能でインストール可能な場合のみインストールされます。推奨側のパッケージがインストールされた後で、(パッケージまたはハードウェアの追加により)推奨対象パッケージが使用可能になった場合は、次のコマンドを使用します。
>
sudo
zypper install-new-recommends
このコマンドは、WebカメラまたはWi-Fiデバイスを接続した後で非常に役に立ちます。このコマンドは、デバイスのドライバと関連ソフトウェアが利用できる場合には、それらをインストールします。ドライバと関連ソフトウェアは、一定のハードウェア依存関係が満たされている場合のみインストールできます。
9.1.4 Zypperによるソフトウェアの更新 #
Zypperを使用してソフトウェアを更新するには3つの方法があります。パッチをインストールする、パッケージの新しいバージョンをインストールする、または配布全体を更新する方法です。最後の方法は、zypper
dist-upgrade
で行うことができます。SUSE Linux Enterprise Serverのアップグレードについては、第2章 「アップグレードパスと方法」を参照してください。
9.1.4.1 必要なすべてのパッチのインストール #
SUSE Linux Enterprise Serverへの「パッチ適用」は、インストールされたパッケージの新しいバージョンをインストールする最も信頼できる方法です。これにより、正しいバージョンを持つ必要なすべてのパッケージがインストールされ、「競合している」とみなされるパッケージバージョンが確実に除外されます。
システムに適用される、正式にリリースされたすべてのパッチをインストールするには、次のコマンドを実行します。
>
sudo
zypper patch
コンピュータに設定されているリポジトリから使用可能なすべてのパッチが、インストール環境に関係があるかどうかが確認されます。関係がある場合(およびoptional
またはfeature
として分類されていない場合)、パッチはただちにインストールされます。zypper patch
が成功すると、例外を確認しない限り、脆弱なバージョンパッケージがインストールされないことが保証されます。正式な更新リポジトリはSUSE Linux Enterprise Serverのインストールを登録した後でのみ使用可能であることに注意してください。
インストールするパッチにシステムの再起動が必要な変更が含まれる場合、事前に警告が表示されます。
プレーンのzypper patch
コマンドでは、サードパーティリポジトリからのパッチは適用されません。サードパーティリポジトリも更新するには、次のようにwith-update
コマンドオプションを使用します。
>
sudo
zypper patch --with-update
オプションのパッチもインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --with-optional
Bugzillaの特定の問題に関連するすべてのパッチをインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --bugzilla=NUMBER
特定のCVEデータベースエントリに関連するすべてのパッチをインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --cve=NUMBER
たとえば、番号がCVE-2010-2713
CVE-のセキュリティパッチをインストールするには、次のコマンドを実行します。
>
sudo
zypper patch --cve=CVE-2010-2713
Zypperおよびパッケージ管理自体に影響するパッチのみをインストールするには、次のコマンドを使用します。
>
sudo
zypper patch --updatestack-only
updatestack-only
コマンドオプションを使用する場合、ほかのリポジトリも更新しようとしてそれ以外のコマンドオプションを指定すると、そのコマンドオプションは削除されます。
9.1.4.2 パッチのリストの表示 #
パッチが使用可能かどうかを確認するため、Zypperでは次の情報を参照できます。
- 必要なパッチの数
必要なパッチ(システムに適用されるパッチであってもまだインストールされていないもの)の数のリストを表示するには、
patch-check
を使用します。>
zypper patch-check Loading repository data... Reading installed packages... 5 patches needed (1 security patch)このコマンドを
--updatestack-only
オプションと組み合わせて使用すると、Zypperおよびパッケージ管理自体に影響するパッチのみのリストを表示できます。- 必要なパッチのリスト
必要なすべてのパッチ(システムに適用されるパッチであってもまだインストールされていないもの)のリストを表示するには、
zypper list-patches
を使用します。- すべてのパッチのリスト
インストール済みかどうか、およびインストール環境に適用されるかどうかに関係なく、SUSE Linux Enterprise Serverで使用可能なすべてのパッチのリストを表示するには、
zypper patches
を使用します。
また、特定の問題に関連するパッチを表示およびインストールすることもできます。特定のパッチを表示するには、次のオプションでzypper
list-patches
コマンドを使用します。
- Bugzillaの問題によって指定する
Bugzillaの問題に関連する、必要なすべてのパッチのリストを表示するには、オプション
--bugzilla
を使用します。特定のバグに対応するパッチのリストを表示するには、
--bugzilla=NUMBER
のようにバグ番号を指定することもできます。Bugzillaの複数の問題に関連するパッチを検索するには、次の例のように、バグ番号の間にカンマを追加します。>
zypper list-patches --bugzilla=972197,956917- CVE番号によって指定する
CVE (Common Vulnerabilities and Exposures)データベースのエントリに関連する、必要なすべてのパッチのリストを表示するには、オプション
--cve
を使用します。特定のCVEデータベースエントリに対応するパッチのリストを表示するには、
--cve=NUMBER
のようにCVE番号を指定することもできます。複数のCVEデータベースエントリに関連するパッチを検索するには、次の例のように、CVE番号の間にカンマを追加します。>
zypper list-patches --cve=CVE-2016-2315,CVE-2016-2324- 撤回されたパッチを一覧表示する
SUSE Linux Enterprise 15のコードストリームでは、一部のパッチが自動的に撤回されます。アップデートに新しいバグが含まれるリスクがあるため、保守アップデートは慎重にテストされます。アップデートにバグが含まれていることが判明した場合、バグのあるアップデートを元に戻すために(バージョン番号が高い)新しいアップデートが発行され、バグのあるアップデートが再度インストールされないようにブロックされます。撤回されたパッチを
zypper
で一覧表示できます。>
zypper lp --all |grep retracted
SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-1965 | recommended | important | --- | retracted | Recommended update for multipath-tools SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-2689 | security | important | --- | retracted | Security update for cpio SLE-Module-Basesystem15-SP3-Updates | SUSE-SLE-Module-Basesystem-15-SP3-2021-3655 | security | important | reboot | retracted | Security update for the Linux Kernel撤回された(または任意の)パッチに関する詳細情報を参照してください。
>
zypper patch-info SUSE-SLE-Product-SLES-15-2021-2689
Loading repository data... Reading installed packages... Information for patch SUSE-SLE-Product-SLES-15-2021-2689: --------------------------------------------------------- Repository : SLE-Product-SLES15-LTSS-Updates Name : SUSE-SLE-Product-SLES-15-2021-2689 Version : 1 Arch : noarch Vendor : maint-coord@suse.de Status : retracted Category : security Severity : important Created On : Mon 16 Aug 2021 03:44:00 AM PDT Interactive : --- Summary : Security update for cpio Description : This update for cpio fixes the following issues: It was possible to trigger Remote code execution due to a integer overflow (CVE-2021-38185, bsc#1189206) UPDATE: This update was buggy and could lead to hangs, so it has been retracted. There will be a follow up update. [...]- 競合するパッケージのパッチ
Information for patch openSUSE-SLE-15.3-2022-333: ------------------------------------------------- Repository : Update repository with updates from SUSE Linux Enterprise 15 Name : openSUSE-SLE-15.3-2022-333 Version : 1 Arch : noarch Vendor : maint-coord@suse.de Status : needed Category : security Severity : important Created On : Fri Feb 4 09:30:32 2022 Interactive : reboot Summary : Security update for xen Description : This update for xen fixes the following issues: - CVE-2022-23033: Fixed guest_physmap_remove_page not removing the p2m mappings. (XSA-393) (bsc#1194576) - CVE-2022-23034: Fixed possible DoS by a PV guest Xen while unmapping a grant. (XSA-394) (bsc#1194581) - CVE-2022-23035: Fixed insufficient cleanup of passed-through device IRQs. (XSA-395) (bsc#1194588) Provides : patch:openSUSE-SLE-15.3-2022-333 = 1 Conflicts : [22] xen.src < 4.14.3_06-150300.3.18.2 xen.noarch < 4.14.3_06-150300.3.18.2 xen.x86_64 < 4.14.3_06-150300.3.18.2 xen-devel.x86_64 < 4.14.3_06-150300.3.18.2 xen-devel.noarch < 4.14.3_06-150300.3.18.2 [...]
上記のパッチは、影響を受けるバージョンまたは脆弱なバージョンの22パッケージと競合します。これらの影響を受けるパッケージまたは脆弱なパッケージのいずれかがインストールされると、競合が発生し、パッチは「必要」に応じて分類されます。
zypper patch
は、利用可能なすべてのパッチをインストールしようとします。問題が発生した場合は、問題が報告され、すべてのアップデートがインストールされるわけではないことが通知されます。この競合は、影響を受けるパッケージまたは脆弱なパッケージを更新するか、それらを削除することで解決できます。SUSEアップデートリポジトリには固定パッケージも付属しているため、アップデートは競合を解決するための標準的な方法です。依存関係の問題やパッケージのロックなどにより、パッケージを更新できない場合は、ユーザの承認後に削除されます。
必要かどうかに関係なくすべてのパッチのリストを表示するには、追加でオプション--all
を使用します。たとえば、CVE番号が割り当てられたすべてのパッチのリストを表示するには、次のコマンドを使用します。
>
zypper list-patches --all --cve
Issue | No. | Patch | Category | Severity | Status
------+---------------+-------------------+-------------+-----------+----------
cve | CVE-2019-0287 | SUSE-SLE-Module.. | recommended | moderate | needed
cve | CVE-2019-3566 | SUSE-SLE-SERVER.. | recommended | moderate | not needed
[...]
9.1.4.3 新規パッケージパージョンのインストール #
リポジトリに新しいパッケージのみが存在し、パッチが提供されていない場合は、zypper patch
は無効です。インストールされているパッケージをすべて新しく入手可能なバージョンで更新するには、次のコマンドを使用します。
>
sudo
zypper update
zypper update
は問題のあるパッケージを無視します。たとえば、パッケージがロックされている場合、zypper update
は、より新しいバージョンのパッケージが利用可能であってもそのパッケージを省略します。逆に、パッケージが脆弱であるとみなされた場合、zypper patch
は競合を報告します。
個別のパッケージをアップデートするには、updateコマンドまたはinstallコマンドのいずれかでパッケージを指定します。
>
sudo
zypper update PACKAGE_NAME>
sudo
zypper install PACKAGE_NAME
インストール可能なすべての新しいパッケージのリストを、次のコマンドで取得できます。
>
zypper list-updates
ただし、このコマンドで表示されるのは、次の条件に一致するパッケージのみです。
すでにインストール済みのパッケージと同じベンダである
すでにインストール済みのパッケージと同等以上の優先度をもつリポジトリによって提供される
インストール可能である(すべての依存関係が満たされている)
次のコマンドを使用すると、(インストール可能かどうかに関わらず)すべての新しい使用可能なパッケージのリストを取得できます。
>
sudo
zypper list-updates --all
新しいパッケージをインストールできない理由を見つけるには、上で説明されているように、zypper
install
コマンドまたはzypper update
コマンドを使用します。
9.1.4.4 孤立パッケージの特定 #
Zypperからリポジトリを削除する場合や、システムをアップグレードする場合には、いくつかのパッケージが「孤立」状態になる可能性があります。これらの孤立パッケージは、どのアクティブなリポジトリにも属していません。次のコマンドで、これらのリストを表示できます。
>
sudo
zypper packages --orphaned
このリストを使用して、パッケージが引き続き必要か、それとも削除しても安全かを判断できます。
9.1.5 削除されたファイルを使用しているプロセスとサービスの特定 #
パッケージにパッチを適用したり、パッケージを更新または削除したりした場合、更新または削除によって削除されたファイルを引き続き使用している実行中のプロセスがシステムに存在することがあります。削除されたファイルを使用しているプロセスのリストを表示するには、zypper ps
を使用します。プロセスが既知のサービスに属している場合は、サービス名のリストが表示され、そのサービスを容易に再起動できます。デフォルトでは、zypper
ps
は次のような表を表示します。
>
zypper ps
PID | PPID | UID | User | Command | Service | Files
------+------+-----+-------+--------------+--------------+-------------------
814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon | /lib64/ld-2.19.s->
| | | | | | /lib64/libdl-2.1->
| | | | | | /lib64/libpthrea->
| | | | | | /lib64/libc-2.19->
[...]
PID: プロセスのID |
PPID: 親プロセスのID |
UID: プロセスを実行しているユーザのID |
UID: プロセスを実行しているユーザのログイン名 |
Command: プロセスを実行するために使用されるコマンド |
Service: サービス名(コマンドがシステムサービスに関連付けられている場合にのみ) |
Files: 削除されたファイルのリスト |
次のように指定することで、zypper ps
の出力フォーマットを制御できます。
zypper ps
-s
削除されたファイルを表示しない短い表を作成します。
>
zypper ps -s PID | PPID | UID | User | Command | Service ------+------+------+---------+--------------+-------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon 817 | 1 | 0 | root | irqbalance | irqbalance 1567 | 1 | 0 | root | sshd | sshd 1761 | 1 | 0 | root | master | postfix 1764 | 1761 | 51 | postfix | pickup | postfix 1765 | 1761 | 51 | postfix | qmgr | postfix 2031 | 2027 | 1000 | tux | bash |zypper ps
-ss
システムサービスに関連付けられているプロセスのみを表示します。
PID | PPID | UID | User | Command | Service ------+------+------+---------+--------------+-------------- 814 | 1 | 481 | avahi | avahi-daemon | avahi-daemon 817 | 1 | 0 | root | irqbalance | irqbalance 1567 | 1 | 0 | root | sshd | sshd 1761 | 1 | 0 | root | master | postfix 1764 | 1761 | 51 | postfix | pickup | postfix 1765 | 1761 | 51 | postfix | qmgr | postfix
zypper ps
-sss
削除されたファイルを使用しているシステムサービスのみを表示します。
avahi-daemon irqbalance postfix sshd
zypper ps
--print "systemctl status %s"
再起動が必要な可能性があるサービスのステータス情報を取得するコマンドを表示します。
systemctl status avahi-daemon systemctl status irqbalance systemctl status postfix systemctl status sshd
サービスの処理の詳細については、第19章 「systemd
デーモン」を参照してください。
9.1.6 Zypperによるリポジトリの管理 #
Zypperのすべてのインストールまたはパッチのコマンドは、既知のリポジトリのリストに応じて異なります。システムで既知のすべてのリポジトリのリストを表示するには、次のコマンドを使用します。
>
zypper repos
結果は、次の出力のようになります。
>
zypper repos
# | Alias | Name | Enabled | Refresh
--+--------------+---------------+---------+--------
1 | SLEHA-15-GEO | SLEHA-15-GEO | Yes | No
2 | SLEHA-15 | SLEHA-15 | Yes | No
3 | SLES15 | SLES15 | Yes | No
各種コマンドのリポジトリを指定するには、エイリアス、URI、またはリポジトリ番号をzypper repos
コマンド出力から使用できます。リポジトリの別名は、リポジトリ操作コマンド用の短いリポジトリ名です。ただし、リポジトリリストの変更後に、リポジトリ番号が変わる可能性があります。エイリアスは変更されることはありません。
デフォルトでは、URIやリポジトリの優先度など、詳細情報は表示されません。すべての詳細を表示するには、次のコマンドを使用します。
>
zypper repos -d
9.1.6.1 リポジトリの追加 #
リポジトリを追加するには、次を実行します。
>
sudo
zypper addrepo URI ALIAS
URIは、インターネットリポジトリ、ネットワークリソース、ディレクトリ、CDまたはDVDのいずれかです(詳細については、https://en.opensuse.org/openSUSE:Libzypp_URIsを参照してください)。ALIASは、リポジトリの短い固有のIDです。このIDは、固有である必要があること以外は自由に選択できます。すでに使用されているエイリアスを指定した場合、Zypperでは警告が発行されます。
9.1.6.2 リポジトリの更新 #
zypper
は、設定されているリポジトリからパッケージの変更点をフェッチできます。変更点をフェッチするには、次のコマンドを実行します。
>
sudo
zypper refresh
zypper
のデフォルトの動作
一部のコマンドではデフォルトでrefresh
が自動的に実行されるため、ユーザがこのコマンドを明示的に実行する必要はありません。
refresh
コマンドと--plus-content
オプションを使用すると、無効になっているリポジトリ内の変更点も表示できます。
>
sudo
zypper --plus-content refresh
このオプションは、リポジトリ内の変更点をフェッチしますが、無効になっているリポジトリは同じ状態(無効)のままにします。
9.1.6.3 リポジトリの削除 #
リストからリポジトリを削除するには、コマンドzypper
removerepo
を使用し、削除するリポジトリのエイリアスまたは番号を指定します。たとえば、SLEHA-12-GEO
から例9.1「Zypper - 既知のリポジトリのリスト」リポジトリを削除するには、次のコマンドのいずれかを使用します。
>
sudo
zypper removerepo 1>
sudo
zypper removerepo "SLEHA-12-GEO"
9.1.6.4 リポジトリの変更 #
zypper modifyrepo
によりリポジトリを有効または無効にします。また、このコマンドにより、リポジトリのプロパティ(動作、名前、優先度の更新など)を変更できます。次のコマンドは、updates
という名前のリポジトリを有効にし、自動更新をオンにし、リポジトリの優先度を20に設定します。
>
sudo
zypper modifyrepo -er -p 20 'updates'
リポジトリを変更する場合、1つのリポジトリだけなく、リポジトリのグループも操作できます。
-a : すべてのリポジトリ |
-l : ローカルリポジトリ |
-t : リモートリポジトリ |
-m TYPE : 特定のタイプのリポジトリ(ここで、TYPEには、次のいずれかを指定できます: http 、https 、ftp 、cd 、dvd 、dir 、file 、cifs 、smb 、nfs 、hd 、iso ) |
リポジトリエイリアスの名前を変更するには、renamerepo
コマンドを使用します。次の例では、エイリアスをMozilla
Firefox
からfirefox
に変更しています。
>
sudo
zypper renamerepo 'Mozilla Firefox' firefox
9.1.7 Zypperによるリポジトリおよびパッケージのクエリ #
Zypperでは、リポジトリまたはパッケージをクエリするためのさまざまな方法が提供されています。使用可能なすべての製品、パターン、パッケージ、またはパッチのリストを取得するには、次のコマンドを使用します。
>
zypper products>
zypper patterns>
zypper packages>
zypper patches
特定のパッケージについてすべてのリポジトリをクエリするには、search
を使用します。特定のパッケージに関する情報を取得するには、info
コマンドを使用します。
9.1.7.1 ソフトウェアの検索 #
zypper 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]/"
9.1.7.2 すべてのSLEモジュール間のパッケージの検索 #
現在有効なSLEモジュールの内部または外部の両方のパッケージを検索するには、search-packages
サブコマンドを使用します。このコマンドは、SUSEカスタマーセンターに連絡し、次のように一致するパッケージのすべてのモジュールを検索します。
>
zypper search-packages package1 package2
zypper search-packages
では、次のオプションを提供します。
検索文字列の完全一致を検索:
-x
,--match-exact
モジュール別に結果をグループ化(デフォルト: パッケージ別にグループ化):
-g,
--group-by-module
パッケージに関する詳細を表示:
-d
,--details
検索結果をXMLで表示:
--xmlout
9.1.7.3 特定の機能の検索 #
特定の機能を提供するパッケージを検索するには、コマンドwhat-provides
を使用します。たとえば、どのパッケージがPerlモジュールSVN::Core
を提供するか確認したい場合は、次のコマンドを使用します。
>
zypper what-provides 'perl(SVN::Core)'
what-provides
PACKAGE_NAME
はrpm -q --whatprovides
PACKAGE_NAMEに似ていますが、RPMではRPMデータベース(つまり、すべてのインストール済みパッケージのデータベース)のみを問い合わせることができます。それに対してZypperは、インストール済みのパッケージだけでなく、すべてのリポジトリから機能のプロバイダに関する情報を表示します。
9.1.7.4 パッケージ情報の表示 #
単一のパッケージをクエリするには、info
を使用し、引数として正確なパッケージ名を指定します。パッケージに関する詳細情報を表示します。パッケージ名がリポジトリのどのパッケージ名にも一致しない場合は、パッケージ以外に一致するものの詳細情報を出力します。特定のタイプを要求して(-t
オプションを使用)、そのタイプが存在しない場合は、使用可能なほかの一致を出力しますが、詳細な情報は出力しません。
ソースパッケージを指定した場合、そのソースパッケージからビルドされたバイナリパッケージを表示します。バイナリパッケージを指定した場合、そのバイナリパッケージをビルドするために使用されたソースパッケージを出力します。
パッケージの要求や推奨も表示するには、--requires
オプションや--recommends
オプションを使用します。
>
zypper info --requires MozillaFirefox
9.1.8 ライフサイクル情報の表示 #
SUSE製品は一般的に10年間サポートされています。多くの場合、3年間のサポートを追加するSUSEの拡張サポート提供を利用して、この標準的なライフサイクルを延長することができます。製品によっては、正確なサポートライフサイクルをhttps://www.suse.com/lifecycleで見つけることができます。
製品とサポートされているパッケージのライフサイクルを確認するには、以下のようにzypper lifecycle
コマンドを使用します。
#
zypper lifecycle
Product end of support Codestream: SUSE Linux Enterprise Server 15 2028-07-31 Product: SUSE Linux Enterprise Server 15 SP3 n/a* Module end of support Basesystem Module n/a* Desktop Applications Module n/a* Server Applications Module n/a* Package end of support if different from product: autofs Now, installed 5.1.3-7.3.1, update available 5.1.3-7.6.1
9.1.9 Zypperの設定 #
Zypperには、現在、設定ファイルが付属しています。この設定ファイルを使用すれば、Zypperの動作を(システム全体またはユーザ固有のでどちらかで)永続的に変更できます。システム全体に渡って変更する場合は、/etc/zypp/zypper.conf
を編集します。ユーザ固有に変更する場合は、~/.zypper.conf
を編集します。~/.zypper.conf
がまだ存在していない場合は、テンプレートとして/etc/zypp/zypper.conf
を使用できます。このテンプレートを~/.zypper.conf
にコピーして、好みに合わせて調整してください。利用できるオプションのヘルプについては、ファイル内のコメントを参照してください。
9.1.10 トラブルシューティング #
設定済みのリポジトリからのパッケージへのアクセスに問題がある場合(たとえば、特定のパッケージがリポジトリの1つに存在することを知っていても、Zypperでそのパッケージを見つけられない場合など)は、次のコマンドでリポジトリを更新すると有効なことがあります。
>
sudo
zypper refresh
それも役に立たない場合は、次のコマンドを試してください。
>
sudo
zypper refresh -fdb
このコマンドは、生メタデータの強制ダウンロードを含むデータベースの完全な更新と再構築を強制します。
9.1.11 BtrfsファイルシステムでのZypperロールバック機能 #
ルートパーティションでBtrfsファイルシステムが使用され、snapper
がインストールされている場合に、ファイルシステムに対する変更をコミットして適切なファイルシステムスナップショットを作成すると、Zypperは自動的にsnapper
を呼び出します。これらのスナップショットは、Zypperによって行われた変更を元に戻す場合に使用できます。詳細については、第10章 「Snapperを使用したシステムの回復とスナップショット管理」を参照してください。
9.1.12 詳細情報 #
コマンドラインからのソフトウェア管理の詳細については、「zypper help
」、「zypper help
COMMAND」と入力するか、zypper(8)
のマニュアルページを参照してください。詳しいコマンドリファレンス、最も重要なコマンドのcheat sheets
、およびスクリプトやアプリケーションにおけるZypperの詳しい使い方については、https://en.opensuse.org/SDB:Zypper_usageを参照してください。SUSE Linux Enterprise Serverの最新バージョンにおけるソフトウェアの変更点のリストについては、https://en.opensuse.org/openSUSE:Zypper_versionsを参照してください。
9.2 RPM - パッケージマネージャ #
RPM (RPM Package Manager)がソフトウェアパッケージを管理するのに使用されます。その主なコマンドはrpm
とrpmbuild
です。ユーザ、システム管理者、およびパッケージの作成者は、強力なRPMデータベースでクエリーを行って、インストールされているソフトウェアに関する情報を取得できます。
rpm
には、ソフトウェアパッケージのインストール、アンインストール、アップデート、RPMデータベースの再構築、RPMベースまたは個別のRPMアーカイブの照会、パッケージの整合性チェック、およびパッケージへの署名の5種類のモードがあります。rpmbuild
は、元のソースからインストール可能なパッケージを作成する場合に使用します。
インストール可能なRPMアーカイブは、特殊なバイナリ形式でパックされています。それらのアーカイブは、インストールするプログラムファイルとある種のメタ情報で構成されます。メタ情報は、ソフトウェアパッケージを設定するためにrpm
によってインストール時に使用されるか、または文書化の目的でRPMデータベースに格納されています。通常、アーカイブには拡張子.rpm
が付けられます。
多くのパッケージにおいて、ソフトウェア開発に必要なコンポーネント(ライブラリ、ヘッダ、インクルードファイルなど)は、別々のパッケージに入れられています。それらの開発パッケージは、最新のGNOMEパッケージのように、ソフトウェアを自分自身でコンパイルする場合にのみ、必要になります。それらのパッケージは、名前の拡張子-devel
で識別できます(alsa-devel
パッケージやgimp-devel
パッケージなど)。
9.2.1 パッケージの信頼性の検証 #
RPMパッケージにはGPG署名があります。RPMパッケージの署名を検証するには、rpm --checksig
PACKAGE-1.2.3.rpmコマンドを使用して、SUSEまたはその他の信頼できるツールから送信されたパッケージかどうか判別します。これは、インターネットからアップデートパッケージを入手する場合には、特に推奨されます。
オペレーティングシステムの問題を修復する場合、暫定修正(PTF)を実動システムにインストールしなければならない場合があります。SUSEから提供されるパッケージは、特別なPTFキーに照らして署名されています。ただし、SUSE Linux Enterprise 11と異なり、SUSE Linux Enterprise 12システムでは、このキーはデフォルトでインポートされません。キーを手動でインポートするには、次のコマンドを使用します。
>
sudo
rpm --import \ /usr/share/doc/packages/suse-build-key/suse_ptf_key.asc
キーをインポートしたら、PTFパッケージをシステムにインストールできます。
9.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」と入力します。解決されていない依存関係がない場合にパッケージのみを削除します。他のアプリケーションがTcl/Tkを必要とする限り、Tcl/Tkを削除することは理論的に不可能です。その場合でも、RPMはデータベースに援助を要求します。他の依存関係が「ない」場合でも、また、どのような理由があってもそのような削除が不可能であれば、--rebuilddb
オプションを使用してRPMデータベースを再構築するのがよいでしょう。
9.2.3 デルタRPMパッケージ #
デルタRPMパッケージには、RPMパッケージの新旧バージョン間の違いが含まれています。デルタRPMを古いRPMに適用すると、まったく新しいRPMになります。デルタRPMは、インストールされているRPMとも互換性があるので、古いRPMのコピーを保管する必要はありません。デルタRPMパッケージは、パッチRPMよりもさらに小さく、パッケージをインターネット上で転送するのに便利です。欠点は、デルタRPMが組み込まれたアップデート操作の場合、そのままのRPMまたはパッチRPMに比べて、CPUサイクルの消費が目立って多くなることです。
makedeltarpm
およびapplydelta
バイナリは、デルタRPMスイート(deltarpm
パッケージ)の一部であり、デルタRPMパッケージの作成と適用に際して役立ちます。次のコマンドを使用して、new.delta.rpm
というデルタRPMを作成できます。次のコマンドでは、old.rpm
およびnew.rpm
が存在することが前提となります。
>
sudo
makedeltarpm old.rpm new.rpm new.delta.rpm
古いパッケージがすでにインストールされていれば、applydeltarpm
を使用して、ファイルシステムから新たにRPMを構築できます。
>
sudo
applydeltarpm new.delta.rpm new.rpm
ファイルシステムにアクセスすることなく、古いRPMから構築するには、-r
オプションを使用します。
>
sudo
applydeltarpm -r old.rpm new.delta.rpm new.rpm
テクニカル詳細については、/usr/share/doc/packages/deltarpm/README
を参照してください。
9.2.4 RPM クエリー #
-q
オプションを使用すると、rpm
はクエリを開始し、(-p
オプションを追加することにより)RPMアーカイブを検査できるようにして、インストールされたパッケージのRPMデータベースでクエリを行えるようにします。必要な情報の種類を指定する複数のスイッチを使用できます。表9.1「基本的なRPMクエリオプション」を参照してください。
|
パッケージ情報 |
|
ファイルリスト |
|
ファイルFILEを含むパッケージでクエリーを行います(FILEにはフルパスを指定する必要があります)。 |
|
ステータス情報を含むファイルリスト( |
|
ドキュメントファイルだけをリストします ( |
|
設定ファイルだけをリストします( |
|
詳細情報を含むファイルリスト( |
|
他のパッケージが |
|
パッケージが要求する機能 |
|
インストールスクリプト(preinstall、postinstall、uninstall) |
たとえば、コマンドrpm -q -i wget
は、例9.2「rpm -q -i wget
」に示された情報を表示します。
rpm -q -i wget
#Name : wget Version : 1.14 Release : 17.1 Architecture: x86_64 Install Date: Mon 30 Jan 2017 14:01:29 CET Group : Productivity/Networking/Web/Utilities Size : 2046483 License : GPL-3.0+ Signature : RSA/SHA256, Thu 08 Dec 2016 07:48:44 CET, Key ID 70af9e8139db7c82 Source RPM : wget-1.14-17.1.src.rpm Build Date : Thu 08 Dec 2016 07:48:34 CET Build Host : sheep09 Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC <https://www.suse.com/> 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. Distribution: SUSE Linux Enterprise 15
オプション-f
が機能するのは、フルパスで完全なファイル名を指定した場合だけです。必要な数のファイル名を指定します。例:
>
rpm -q -f /bin/rpm /usr/bin/wget
rpm-4.14.1-lp151.13.10.x86_64
wget-1.19.5-lp151.4.1.x86_64
ファイル名の一部分しかわからない場合は、例9.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
PACKAGEコマンドは、特定のパッケージに関する詳細な変更情報を日付順に表示します。
インストールされた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つのバックアップのサイズは、1 GBの/usr
に対しておよそ1 MBです。
9.2.5 ソースパッケージのインストールとコンパイル #
すべてのソースパッケージには、拡張子.src.rpm
(ソースRPM)が付けられています。
ソースパッケージは、インストールメディアからハードディスクにコピーされ、YaSTを使用して展開できます。ただし、ソースパッケージは、パッケージマネージャでインストール済み([i]
)というマークは付きません。これは、ソースパッケージがRPMデータベースに入れられないためです。インストールされたオペレーティングシステムソフトウェアだけがRPMデータベースにリストされます。ソースパッケージを「インストールする」場合、ソースコードだけがシステムに追加されます。
/usr/src/packages
のrpm
とrpmbuild
では、以下のディレクトリが使用できる必要があります(/etc/rpmrc
のようなファイルでカスタム設定を指定している場合を除く)。
SOURCES
元のソース(
.tar.bz2
または.tar.gz
ファイルなど)およびディストリビューション固有の調整(ほとんど.diff
または.patch
ファイル)用です。SPECS
「ビルド」処理を制御する、メタMakefileに類似した
.spec
ファイル用です。BUILD
すべてのソースは、このディレクトリでアンパック、パッチ、およびコンパイルされます。
RPMS
完成したバイナリパッケージが格納されます。
SRPMS
ソースRPMが格納されます。
YaSTを使ってソースパッケージをインストールすると、必要なすべてのコンポーネントが/usr/src/packages
にインストールされます。ソースと調整はSOURCES
、関連する.spec
ファイルはSPECS
に格納されます。
システムコンポーネント(glibc
、rpm
など)で実験を行わないでください。システムが正しく動作しなくなります。
次の例は、wget.src.rpm
パッケージを使用します。ソースパッケージをインストールすると、次のようなファイルが生成されます。
/usr/src/packages/SOURCES/wget-1.19.5.tar.bz2 /usr/src/packages/SOURCES/wgetrc.patch /usr/src/packages/SPECS/wget.spec
rpmbuild
-bX
/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
-i
コマンドまたはrpm
-U
コマンドでインストールできます。rpm
を使用したインストールは、RPMデータベースに登場します。
specファイルのBuildRoot
ディレクティブは非推奨です。この機能がまだ必要な場合は、回避方法として--buildroot
オプションを使用してください。
9.2.6 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
を使用するか、build
のマニュアルページを参照してアクセスしてください。
9.2.7 RPMアーカイブとRPMデータベース用のツール #
Midnight Commander (mc
)は、RPMアーカイブの内容を表示し、それらの一部をコピーできます。アーカイブを仮想ファイルシステムとして表し、Midnight Commanderの通常のメニューオプションを使用できます。F3キーを使用してHEADER
を表示します。カーソルキーとEnterキーを使ってアーカイブ構造を表示します。F5キーを使用してアーカイブコンポーネントをコピーします。
フル機能のパッケージマネージャをYaSTモジュールとして使用できます詳細については、第8章 「ソフトウェアをインストールまたは削除する」を参照してください。