Menu Close

Red Hat Training

A Red Hat training course is available for Red Hat Enterprise Linux

第4章 高度なトピック

本セクションでは、入門的なチュートリアルの範囲外のトピックについて説明しますが、実際の RPM パッケージ化で役に立ちます。

4.1. パッケージの署名

サードパーティーがそのコンテンツを変更できないようにパッケージに署名を行います。ユーザーは、パッケージをダウンロードする際に HTTPS プロトコルを使用して、セキュリティーをさらに強化できます。

パッケージの署名には、以下の 3 つの方法があります。

4.1.1. GPG キーの作成

手順

  1. GNU Privacy Guard (GPG) キーペアを生成します。

    # gpg --gen-key
  2. 生成したキーを確認し、表示します。

    # gpg --list-keys
  3. 公開鍵をエクスポートします。

    # gpg --export -a '<Key_name>' > RPM-GPG-KEY-pmanager
    注記

    <Key_name> の代わりにキーに対して選択した実際の名前を含めます。

  4. エクスポートした公開鍵を RPM データベースにインポートします。

    # rpm --import RPM-GPG-KEY-pmanager

4.1.2. 既存パッケージへの署名の追加

このセクションでは、署名なしでパッケージを構築する場合に最も役立つケースを説明します。この署名は、パッケージのリリースの直前に追加されます。

パッケージに署名を追加するには、rpm -sign パッケージで使用できる --addsign を指定します。

複数の署名があると、パッケージ作成者からエンドユーザーに、パッケージの所有権のパスを記録できます。

手順

  • パッケージに署名を追加します。

    $ rpm --addsign blather-7.9-1.x86_64.rpm
    注記

    署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。

4.1.3. 複数の署名のあるパッケージの署名の確認

手順

  • 複数の署名を持つパッケージの署名を確認するには、以下のコマンドを実行します。

    $ rpm --checksig blather-7.9-1.x86_64.rpm
    blather-7.9-1.x86_64.rpm: size pgp pgp md5 OK

    rpm --checksig コマンドの出力の 2 つの pgp 文字列は、パッケージが回署名されていることを示しています。

4.1.4. 既存のパッケージに署名を追加する実用的な例

本セクションでは、既存のパッケージへの署名の追加が役立つ状況の例を示します。

ある会社の部門が、パッケージを作成し、その部門のキーで署名を行います。次に、本社がパッケージの署名を確認します。次に、そのパッケージにコーポレート署名を追加し、その署名されたパッケージが本物であることを表明します。

これら 2 つの署名が付いた状態で、パッケージが小売商に送られます。この小売商は、署名をチェックし、一致を確認して自身の署名も追加します。

そして、このパッケージは、このパッケージを展開したいと思う会社へと向かいます。パッケージ上の署名をすべて確認すれば、その署名が正式コピーであることが分かります。パッケージが企業の承認を受けたことを従業員に通知するために、その会社独自の署名を追加するかどうかは、パッケージ導入を行う会社の内部管理によって決まります。

4.1.5. 既存のパッケージの署名の置き換え

この手順では、各パッケージを再構築せずに公開鍵を変更する方法を説明します。

手順

  • 公開鍵を変更するには、次のコマンドを実行します。

    $ rpm --resign blather-7.9-1.x86_64.rpm
    注記

    署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。

また、以下の手順で示しているように、--resign オプションを指定すると、複数のパッケージの公開鍵を変更できます。

手順

  • 複数のパッケージの公開鍵を変更するには、以下のコマンドを実行します。

    $ rpm --resign b*.rpm
    注記

    署名の秘密鍵のロックを解除するには、パスワードを入力する必要があります。

4.1.6. ビルド時のパッケージの署名

手順

  1. rpmbuild コマンドを使用して、パッケージを構築します。

    $ rpmbuild blather-7.9.spec
  2. --addsign オプションを指定して、rpmsign コマンドでパッケージに署名します。

    $ rpmsign --addsign blather-7.9-1.x86_64.rpm
  3. 必要に応じて、パッケージの署名を確認します。
$ rpm --checksig blather-7.9-1.x86_64.rpm
blather-7.9-1.x86_64.rpm: size pgp md5 OK
注記

複数のパッケージのビルドと署名を行う場合は、以下の構文を使用して Pretty good Privacy (PGP) パスフレーズを複数回入力しないようにします。

$ rpmbuild -ba --sign b*.spec

署名の秘密鍵のロックを解除にはパスワードを入力する必要があることに注意してください。

4.2. マクロの詳細

本セクションでは、選択したビルトイン RPM マクロについて説明します。そのようなマクロの完全なリストは、「RPM ドキュメンテーション」を参照してください。

4.2.1. 独自のマクロの定義する

次のセクションでは、カスタムマクロの作成方法を説明します。

手順

  • RPM SPEC ファイルに以下の行を含めます。

    %global <name>[(opts)] <body>

\ の周りの空白すべてが削除されます。名前は英数字と _ で構成できます。最低でも 3 文字で指定する必要があります。(opts) フィールドの指定は任意です。

  • Simple マクロには、(opts) フィールドは含まれません。この場合、再帰的なマクロ拡張のみが実行されます。
  • Parametrized マクロには、(opts) フィールドが含まれます。括弧で囲まれている opts 文字列は、マクロ呼び出しの開始時に argc/argv 処理の getopt (3) に渡されます。
注記

古い RPM SPEC ファイルは、代わりに % define <name> <body> マクロパターンを使用します。%define マクロと %global マクロの違いは次のとおりです。

  • %define にはローカルスコープがあります。これは、SPEC ファイルの特定の部分に適用されます。使用時に、%define マクロの本文が展開されます。
  • %global にはグローバルスコープがあります。これは SPEC ファイル全体に適用されます。%global マクロの本文は、定義時に展開されます。
重要

マクロは、コメントアウトされた場合でも、マクロ名が SPEC ファイルの %changelog に指定されている場合でも評価されます。マクロをコメントアウトするには %% を使用します。例: %%global

関連情報

マクロ機能に関する包括的な情報は、「RPM ドキュメント」を参照してください。

4.2.2. %setup マクロの使用

このセクションでは、%setup マクロの異なるバリアントを使用して、ソースコード tarball でパッケージを構築する方法を説明します。マクロのバリアントは組み合わせることができることに注意してください。rpmbuild の出力は、%setup マクロの標準的な動作を示しています。各フェーズの開始時に、マクロは以下の例のように Executing(%…) を出力します。

例4.1 %setup マクロの出力例

Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.DhddsG

シェルの出力は、set -x enabled で設定されます。/var/tmp/rpm-tmp.DhddsG の内容を表示するには、--debug オプションを指定します。これは、rpmbuild により、ビルドの作成後に一時ファイルが削除されるためです。環境変数の設定の後に、以下のような設定が表示されます。

cd '/builddir/build/BUILD'
rm -rf 'cello-1.0'
/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xof -
STATUS=$?
if [ $STATUS -ne 0 ]; then
  exit $STATUS
fi
cd 'cello-1.0'
/usr/bin/chmod -Rf a+rX,u+w,g-w,o-w .

%setup マクロ:

  • 正しいディレクトリーで作業していることを確認します。
  • 以前のビルドで残ったファイルを削除します。
  • ソース tarball を展開します。
  • 一部のデフォルト権限を設定します。

4.2.2.1. %setup -q マクロの使用

-q オプションでは、%setup マクロの冗長性が制限されます。tar -xvof の代わりに tar -xof のみが実行されます。このオプションは、最初のオプションとして使用します。

4.2.2.2. %setup -n マクロの使用

- n オプションは、拡張 tarball からディレクトリー名を指定します。

展開した tarball のディレクトリーの名前が、想定される名前 (%{name}-%{version} と異なる場合に、これを使用すると、%setup マクロのエラーが発生することがあります。

たとえば、パッケージ名が cello で、ソースコードが hello-1.0.tgz でアーカイブされ、hello/ ディレクトリーが含まれている場合、SPEC ファイルのコンテンツは次のようになります。

Name: cello
Source0: https://example.com/%{name}/release/hello-%{version}.tar.gz
…
%prep
%setup -n hello

4.2.2.3. %setup -c マクロの使用

-c オプションは、ソースコード tarball にサブディレクトリーが含まれておらず、展開後に、アーカイブのファイルで現在のディレクトリーを埋める場合に使用されます。

次に、-c オプションによりディレクトリーが作成され、以下のようにアーカイブ展開手順に映ります。

/usr/bin/mkdir -p cello-1.0
cd 'cello-1.0'

このディレクトリーは、アーカイブ拡張後も変更されません。

4.2.2.4. %setup -D マクロおよび %setup -T マクロの使用

- D オプションは、ソースコードのディレクトリーの削除を無効するため、%setup マクロを複数回使用する場合に特に便利です。-D オプションでは、次の行は使用されません。

rm -rf 'cello-1.0'

- T オプションは、スクリプトから以下の行を削除して、ソースコード tarball の拡張を無効にします。

/usr/bin/gzip -dc '/builddir/build/SOURCES/cello-1.0.tar.gz' | /usr/bin/tar -xvvof -

4.2.2.5. %setup -a マクロおよび %setup -b マクロの使用

-a オプションおよび -b オプションは、特定のソースを拡張します。

-b オプションは before を意味し、作業ディレクトリーに移動する前に特定のソースを展開します。-a オプションは after を意味し、移動後にそのソースを展開します。これらの引数は、SPEC ファイルのプリアンブルからのソース番号です。

以下の例では、cello-1.0.tar.gz アーカイブに空の example ディレクトリーが含まれています。サンプルは、別の example.tar.gz tarball に同梱されており、同じ名前のディレクトリーに展開されます。この場合、作業ディレクトリーに移動してから Source1 を展開する場合は、-a 1 を指定します。

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: examples.tar.gz
…
%prep
%setup -a 1

以下の例では、サンプルは cello-1.0-examples.tar.gz tarball にあり、cello-1.0/examples に展開されます。この場合、作業ディレクトリーに移動する前に、-b 1 を指定して Source1 を展開します。

Source0: https://example.com/%{name}/release/%{name}-%{version}.tar.gz
Source1: %{name}-%{version}-examples.tar.gz
…
%prep
%setup -b 1

4.2.3. %files セクション共通の RPM マクロ

このセクションでは、SPEC ファイルの %files セクションで必要となる高度な RPM マクロを紹介します。

表4.1 %files セクションの高度な RPM マクロ

マクロ定義

%license

マクロは、LICENSE ファイルとしてリストされているファイルを識別します。そしてインストールされ、RPM などとしてラベルが付けられます。例: %license LICENSE

%doc

マクロは、ドキュメントとしてリストされるファイルを識別して、RPM によりインストールされ、ラベル付けされます。このマクロは、パッケージソフトウェアに関するドキュメントや、コード例や、付随するさまざまなアイテムに使用されます。コードの例が含まれる場合は、実行ファイルから実行可能モードを削除するように注意してください。例: %doc README

%dir

このマクロは、そのパスが、この RPM が所有するディレクトリーとなるようにします。これは、RPM ファイルマニフェストが、アンインストール時にどのディレクトリーをクリーンアップするかを正確に認識できるようにするために重要です。例: %dir %{_libdir}/%{name}

%config (noreplace)

このマクロにより、次のファイルが設定ファイルであることが保証されます。そのため、ファイルを元のインストールチェックサムから修正しても、パッケージのインストールまたは更新で上書き (または置き換え) しないでください。変更がある場合は、アップグレード時またはインストール時にファイル名の末尾に .rpmnew を追加してファイルが作成され、ターゲットシステム上の既存ファイルまたは変更されたファイルが変更されないようにします。例: %config (noreplace) %{_sysconfdir}/%{name}/%{name}.conf

4.2.4. ビルトインマクロの表示

複数のビルトイン RPM マクロを指定します。

手順

  1. ビルトイン RPM マクロをすべて表示するには、以下のコマンドを実行します。

    rpm --showrc
    注記

    出力のサイズは非常に大きくなります。結果を絞り込むには、grep コマンドとともに上記のコマンドを使用します。

  2. システムの RPM バージョン用の RPM マクロに関する情報を確認するには、以下のコマンドを実行します。

    rpm -ql rpm
    注記

    RPM マクロは、出力ディレクトリー構造の macros というタイトルのファイルです。

4.2.5. RPM ディストリビューションマクロ

パッケージ化しているソフトウェアの言語実装や、ディストリビューションの特定のガイドラインに基づいて提供する推奨 RPM マクロセットは、ディストリビューションによって異なります。

多くの場合、推奨される RPM マクロセットは RPM パッケージとして提供され、yum パッケージマネージャーでインストールできます。

インストールすると、マクロファイルは、/usr/lib/rpm/macros.d/ ディレクトリーに配置されます。

raw RPM マクロ定義を表示するには、以下のコマンドを実行します。

rpm --showrc

上記の出力では、raw RPM マクロ定義が表示されます。

RPM のパッケージ化を行う際のマクロの機能や、マクロがどう役立つかを確認するには、rpm --eval コマンドに、引数として使用するマクロの名前を付けて実行します。

rpm --eval %{_MACRO}

詳細は rpm の man ページを参照してください。

4.2.5.1. カスタムマクロの作成

~/.rpmmacros ファイル内のディストリビューションマクロは、カスタムマクロで上書きできます。加えた変更は、マシン上のすべてのビルドに影響します。

警告

~/.rpmmacros ファイルで新しいマクロを定義することは推奨されません。このようなマクロは、ユーザーがパッケージを再構築する可能性がある他のマシンには存在しません。

マクロを上書きするには、次のコマンドを実行します。

%_topdir /opt/some/working/directory/rpmbuild

上記の例から、rpmde-setuptree ユーティリティーを使用して、すべてのサブディレクトリーを含むディレクトリーを作成できます。このマクロの値は、デフォルトでは ~/rpmbuild です。

%_smp_mflags -l3

上記のマクロは、Makefile に渡すためによく使用されます。たとえば、make %{?_smp_mflags} と、ビルドフェーズ時に多数の同時プロセスを設定します。デフォルトでは、-jX に設定されています。X は多数のコアです。コア数を変すると、パッケージビルドの速度アップまたはダウンを行うことができます。

4.3. Epoch、Scriptlets、Triggers

このセクションでは、RMP SPEC ファイルの高度なディレクティブを表す EpochScriptletTriggers について説明します。

これらのディレクティブはすべて、SPEC ファイルだけでなく、生成された RPM がインストールされているエンドマシンにも影響します。

4.3.1. Epoch ディレクティブ

Epoch ディレクティブでは、バージョン番号に基づいて加重依存関係を定義できます。

このディレクティブが RPM SPEC ファイルにない場合、Epoch ディレクティブは全く設定されません。これは、Epoch を設定しないと Epoch が 0 になるという一般的な考え方に反しています。ただし、YUM ユーティリティーは、depsolve の目的で、0 の Epoch と同様に設定されていない Epoch を処理します。

ただし、SPEC ファイルでの Epoch の 一覧は通常省略されます。これは、多くの場合、Epoch 値を導入すると、パッケージのバージョンを比較する際に、想定される RPM 動作がスキューされるためです。

例4.2 Epoch の使用

Epoch: 1 および Version: 1.0foobar パッケージをインストールし、他のユーザーが Version 2.0foobar をパッケージ化します。ただし、Epoch ディレクティブがない場合、新しいバージョンは更新とはみなされません。RPM パッケージ用のバージョン管理を示す従来の Name-Version-Release ラッパーよりも、Epoch バージョンが推奨されている理由。

Epoch を使用することはほとんどありません。ただし、Epoch は 、通常、アップグレードの順序の問題を解決するために使用されます。この問題は、ソフトウェアバージョン番号のスキームや、エンコードに基づいて確実に比較できないアルファベット文字を組み込んだバージョンにおける、アップストリームによる変更の副次的効果として見られる場合があります。

4.3.2. Scriptlets

Scriptlets は、パッケージがインストールまたは削除される前または後に実行される一連の RPM ディレクティブです。

Scriptlets は、ビルド時またはスタートアップスクリプト内で実行できないタスクにのみ使用します。

4.3.2.1. Scriptlets ディレクティブ

共通の Scriptlet ディレクティブのセットがあります。これは、SPEC ファイルセクションのヘッダー (%build%install など) と似ています。これは、標準の POSIX シェルスクリプトとしてよく書かれる、マルチラインのコードセグメントによって定義されます。ただし、ターゲットマシンのディストリビューションの RPM が対応する他のプログラミング言語で書くこともできます。RPM ドキュメントには、利用可能な言語の完全なリストが含まれます。

以下の表には、実行順の Scriptlet ディレクティブの一覧が含まれます。スクリプトを含むパッケージは、%pre%post ディレクティブの間にインストールされ、%preun ディレクティブと %postun ディレクティブ間でアンインストールされることに注意してください。

表4.2 Scriptlet ディレクティブ

ディレクティブ定義

%pretrans

パッケージのインストールまたは削除の直前に実行されるスクリプトレット。

%pre

ターゲットシステムにパッケージをインストールする直前に実行されるスクリプトレット。

%post

ターゲットシステムにパッケージがインストールされた直後に実行されるスクリプトレット。

%preun

ターゲットシステムからパッケージをアンインストールする直前に実行されるスクリプトレット。

%postun

ターゲットシステムからパッケージをアンインストールした直後に実行されるスクリプトレット。

%posttrans

トランザクションの最後に実行されるスクリプトレット。

4.3.2.2. スクリプトレット実行の無効化

スクリプトレットの実行を無効にするには、rpm コマンドに --no_scriptlet_name_ オプションを指定して使用します。

手順

  • たとえば、%pretrans スクリプトレットの実行を無効にするには、次のコマンドを実行します。

    # rpm --nopretrans

    -- noscripts オプションも使用できます。これは、以下のすべてと同等になります。

    • --nopre
    • --nopost
    • --nopreun
    • --nopostun
    • --nopretrans
    • --noposttrans

関連情報

  • 詳細は、man ページの rpm(8) を参照してください。

4.3.2.3. スクリプトレットマクロ

Scriptlets ディレクティブは、RPM マクロでも機能します。

以下の例は、systemd スクリプトレットマクロの使用を示しています。これにより、systemd は新しいユニットファイルについて通知されるようになります。

$ rpm --showrc | grep systemd
-14: transaction_systemd_inhibit %{plugindir}/systemd_inhibit.so
-14: _journalcatalogdir /usr/lib/systemd/catalog
-14: _presetdir /usr/lib/systemd/system-preset
-14: _unitdir   /usr/lib/systemd/system
-14: _userunitdir       /usr/lib/systemd/user
/usr/lib/systemd/systemd-binfmt %{?} >/dev/null 2>&1 || : /usr/lib/systemd/systemd-sysctl %{?} >/dev/null 2>&1 || :
-14: systemd_post
-14: systemd_postun
-14: systemd_postun_with_restart
-14: systemd_preun
-14: systemd_requires
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
-14: systemd_user_post  %systemd_post --user --global %{?} -14: systemd_user_postun %{nil} -14: systemd_user_postun_with_restart %{nil} -14: systemd_user_preun systemd-sysusers %{?} >/dev/null 2>&1 || :
echo %{?} | systemd-sysusers - >/dev/null 2>&1 || : systemd-tmpfiles --create %{?} >/dev/null 2>&1 || :

$ rpm --eval %{systemd_post}

if [ $1 -eq 1 ] ; then
        # Initial installation
        systemctl preset  >/dev/null 2>&1 || :
fi

$ rpm --eval %{systemd_postun}

systemctl daemon-reload >/dev/null 2>&1 || :

$ rpm --eval %{systemd_preun}

if [ $1 -eq 0 ] ; then
        # Package removal, not upgrade
        systemctl --no-reload disable  > /dev/null 2>&1 || :
        systemctl stop  > /dev/null 2>&1 || :
fi

4.3.3. Triggers ディレクティブ

Triggers は、パッケージのインストールおよびアンインストール時に対話できる手段を提供する RPM ディレクティブです。

警告

Triggers は、含まれるパッケージの更新など、予期できないタイミングで実行できます。Triggers はデバッグが難しいため、予期せず実行されたときに破損しないように、安定したな方法で実装する必要があります。このため、Red Hat では、 of Triggers の使用は最小限に抑えることを推奨します。

実行の順序と、既存の各 Triggers の詳細を以下に示します。

all-%pretrans
…
any-%triggerprein (%triggerprein from other packages set off by new install)
new-%triggerprein
new-%pre      for new version of package being installed
…           (all new files are installed)
new-%post     for new version of package being installed

any-%triggerin (%triggerin from other packages set off by new install)
new-%triggerin
old-%triggerun
any-%triggerun (%triggerun from other packages set off by old uninstall)

old-%preun    for old version of package being removed
…           (all old files are removed)
old-%postun   for old version of package being removed

old-%triggerpostun
any-%triggerpostun (%triggerpostun from other packages set off by old un
            install)
…
all-%posttrans

上記の項目は、/usr/share/doc/rpm-4.*/triggers ファイルにあります。

4.3.4. SPEC ファイルでのシェルスクリプト以外のスクリプトの使用

SPEC ファイルの -p スクリプトレットオプションを指定すると、ユーザーはデフォルトのシェルスクリプトインタープリター (-p /bin/sh) の代わりに特定のインタープリターを起動することができます。

次の手順では、pello.py プログラムのインストール後にメッセージを出力するスクリプトの作成方法を説明します。

手順

  1. pello.spec ファイルを開きます。
  2. 以下の行を見つけます。

    install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/
  3. 上記の行の下に、以下を挿入します。

    %post -p /usr/bin/python3
    print("This is {} code".format("python"))
  4. パッケージをインストールします。

    # yum install /home/<username>/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
  5. インストール後に出力メッセージを確認します。

    Installing       : pello-0.1.2-1.el8.noarch                              1/1
    Running scriptlet: pello-0.1.2-1.el8.noarch                              1/1
    This is python code
注記

Python 3 スクリプトを使用するには、SPEC ファイルの install -m に次の行を含めます。

%post -p /usr/bin/python3

Lua スクリプトを使用するには、SPEC ファイルの install -m に次の行を含めます。

%post -p <lua>

これにより、SPEC ファイル内で任意のインタープリターを指定できます。

4.4. RPM 条件

RPM 条件により、さまざまなバージョンの SPEC ファイルを条件付きで含めることができます。

条件を含めるには通常、次を処理します。

  • アーキテクチャー固有のセクション
  • オペレーティングシステム固有のセクション
  • さまざまなバージョンのオペレーティング間の互換性の問題
  • マクロの存在と定義

4.4.1. RPM 条件構文

RPM 条件では、次の構文を使用します。

expression が真であれば、以下のアクションを実行します。

%if expression
…
%endif

expression が真であれば、別のアクションを実行し、別の場合には別のアクションを実行します。

%if expression
…
%else
…
%endif

4.4.2. RPM 条件例

このセクションでは、RPM 条件の例を複数示します。

4.4.2.1. %if 条件

例4.3 RHEL 8 と他のオペレーティングシステム間の互換性を処理するために %if 条件を使用

%if 0%{?rhel} == 8
sed -i '/AS_FUNCTION_DESCRIBE/ s/^//' configure.in sed -i '/AS_FUNCTION_DESCRIBE/ s/^//' acinclude.m4
%endif

この条件では、AS_FUNCTION_DESCRIBE マクロのサポート上、RHEL 8 と他のオペレーティングシステム間の互換性が処理されます。パッケージが RHEL 用に構築されている場合は、%rhel マクロが定義され、RHEL バージョンに展開されます。値が 8 の場合、パッケージは RHEL 8 用にビルドされ、RHEL 8 で対応していない AS_FUNCTION_DESCRIBE への参照が autoconfig スクリプトから削除されます。

例4.4 %if 条件を使用したマクロの定義の処理す

%define ruby_archive %{name}-%{ruby_version}
%if 0%{?milestone:1}%{?revision:1} != 0
%define ruby_archive %{ruby_archive}-%{?milestone}%{?!milestone:%{?revision:r%{revision}}}
%endif

この条件では、マクロの定義を処理します。%milestone マクロまたは %revision マクロが設定されている場合は、アップストリームの tarball の名前を定義する %ruby_archive マクロが再定義されます。

4.4.2.2. %if 条件の特殊なバリアント

%ifarch 条件、%ifnarch 条件、%ifos 条件は、%if 条件の特殊なバリアントです。これらのバリアントは一般的に使用されるため、独自のマクロがあります。

4.4.2.2.1. %ifarch 条件

%ifarch 条件は、アーキテクチャー固有の SPEC ファイルのブロックを開始するために使用されます。この後に、アーキテクチャー指定子が続きます。これらは、それぞれコンマまたは空白で区切ります。

例4.5 %ifarch 条件の使用例

%ifarch i386 sparc
…
%endif

%ifarch%endif の間にある SPEC ファイルのすべてのコンテンツは、32 ビット AMD および Intel のアーキテクチャー、または SunMAJOROS ベースのシステムでのみ処理されます。

4.4.2.2.2. %ifnarch 条件

% ifnarch 条件には、%ifarch 条件よりもリバース論理があります。

例4.6 %ifnarch 条件の使用例

%ifnarch alpha
…
%endif

SPEC ファイルの % ifnarch% endif との間のすべてのコンテンツは、Digital Alpha/AXP ベースのシステムで処理されない場合に限り処理されます。

4.4.2.2.3. %ifos 条件

%ifos 条件は、ビルドのオペレーティングシステムに基づいて処理を制御するために使用されます。その後に複数のオペレーティングシステム名を指定できます。

例4.7 %ifos 条件の使用例

%ifos linux
…
%endif

SPEC ファイルの %ifos%endif と の間のすべてのコンテンツは、ビルドが Linux システムで実行された場合にのみ処理されます。