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

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

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

ブラケットで囲まれたコンポーネントは必須ではありません。一般的なオプションおよびすべてのコマンドのリストについては、zypper helpを参照してください。特定のコマンドのヘルプを参照するには、「zypper help COMMAND」と入力します。

上記のすべてを結合できます。たとえば、次のコマンドは、冗長モードで、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

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

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

> sudo zypper install PACKAGE_NAME
> sudo zypper remove PACKAGE_NAME

警告: 必須システムパッケージは削除しないでください

glibc、zypper、kernelなどの必須システムパッケージは削除しないでください。これらを削除すると、システムが不安定になったり、まったく動作しなくなったりする可能性があります。

> sudo zypper install emacs -vim

> sudo zypper remove emacs +vim

> sudo zypper install -emacs +vim       # Wrong
> sudo zypper install vim -emacs        # Correct
> sudo zypper install -- -emacs +vim    # Correct
> sudo zypper remove emacs +vim         # Correct

> sudo zypper rm --clean-deps PACKAGE_NAME

> sudo zypper --non-interactive install PACKAGE_NAME

> zypper source-install PACKAGE_NAME

> sudo zypper source-install -D PACKAGE_NAME

> sudo zypper source-install -d PACKAGE_NAME

> zypper search -t srcpackage

> zypper source-download

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をコンピュータのドライブに挿入するなどして、メディアが使用可能であることを確認してください。

> zypper verify

> sudo zypper install-new-recommends

Zypperを使用してソフトウェアを更新するには3つの方法があります。パッチをインストールする、パッケージの新しいバージョンをインストールする、または配布全体を更新する方法です。最後の方法は、zypper dist-upgradeで行うことができます。SUSE Linux Enterprise Serverのアップグレードについては、第1章 「アップグレードパスと方法」を参照してください。

> sudo zypper patch

> sudo zypper patch --with-update

> sudo zypper patch --with-optional

> sudo zypper patch --bugzilla=NUMBER

> sudo zypper patch --cve=NUMBER

> sudo zypper patch --cve=CVE-2010-2713

> sudo zypper patch --updatestack-only

> 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コマンドを使用します。

> sudo zypper packages --orphaned

パッケージにパッチを適用したり、パッケージを更新または削除したりした場合、更新または削除によって削除されたファイルを引き続き使用している実行中のプロセスがシステムに存在することがあります。削除されたファイルを使用しているプロセスのリストを表示するには、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->
[...]

次のように指定することで、zypper psの出力フォーマットを制御できます。

サービスの処理の詳細については、第19章 「systemdデーモン」を参照してください。

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

> sudo zypper addrepo URI ALIAS

9.1.6.2 リポジトリの更新 #

 

zypperは、設定されているリポジトリからパッケージの変更点をフェッチできます。変更点をフェッチするには、次のコマンドを実行します。

> sudo zypper refresh

注記: zypperのデフォルトの動作

一部のコマンドではデフォルトでrefreshが自動的に実行されるため、ユーザがこのコマンドを明示的に実行する必要はありません。

refreshコマンドと--plus-contentオプションを使用すると、無効になっているリポジトリ内の変更点も表示できます。

> sudo zypper --plus-content refresh

このオプションは、リポジトリ内の変更点をフェッチしますが、無効になっているリポジトリは同じ状態(無効)のままにします。

> sudo zypper removerepo 1
> sudo zypper removerepo "SLEHA-12-GEO"

> sudo zypper modifyrepo -er -p 20 'updates'

> sudo zypper renamerepo 'Mozilla Firefox' firefox

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

> zypper products
> zypper patterns
> zypper packages
> zypper patches

特定のパッケージについてすべてのリポジトリをクエリするには、searchを使用します。特定のパッケージに関する情報を取得するには、infoコマンドを使用します。

> zypper search-packages package1 package2

> zypper what-provides 'perl(SVN::Core)'

> zypper info --requires MozillaFirefox

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

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

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

> sudo zypper refresh

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

> sudo zypper refresh -fdb

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

ルートパーティションでBtrfsファイルシステムが使用され、snapperがインストールされている場合に、ファイルシステムに対する変更をコミットして適切なファイルシステムスナップショットを作成すると、Zypperは自動的にsnapperを呼び出します。これらのスナップショットは、Zypperによって行われた変更を元に戻す場合に使用できます。詳細については、第10章 「Snapperを使用したシステムの回復とスナップショット管理」を参照してください。

コマンドラインからのソフトウェア管理の詳細については、「zypper help」、「zypper help  COMMAND」と入力するか、zypper(8)のマニュアルページを参照してください。詳しいコマンドリファレンス、最も重要なコマンドの早見表、およびスクリプトやアプリケーションにおけるZypperの詳しい使い方については、https://en.opensuse.org/SDB:Zypper_usageを参照してください。SUSE Linux Enterprise Serverの最新バージョンにおけるソフトウェアの変更点のリストについては、https://en.opensuse.org/openSUSE:Zypper_versionsを参照してください。

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パッケージをシステムにインストールできます。

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

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

アップデートが終了したら、.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が存在することが前提となります。

> 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を参照してください。

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

たとえば、コマンドrpm -q -i wgetは、例9.2「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文字の記号を使用して、次の変更に関するいくつかのヒントを提供します。

設定ファイルの場合は、文字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、関連する.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のドキュメントを参照してください)。以下に簡単な説明を示します。

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

specファイルのBuildRootディレクティブは非推奨です。この機能がまだ必要な場合は、回避方法として--buildrootオプションを使用してください。

多くのパッケージにつきものの不都合は、ビルド処理中に不要なファイルが稼働中のシステムに追加されてしまうことです。これを回避するには、パッケージのビルド先の定義済みの環境を作成する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モジュールとして使用できます詳細については、第8章 「ソフトウェアをインストールまたは削除する」を参照してください。