ネイティブにコンパイルされたソフトウェアは、生成されたバイナリーの実行ファイルでマシンコードにコンパイルされるプログラミング言語で書かれたソフトウェアです。ネイティブにコンパイルされたソフトウェアはスタンドアロンソフトウェアです。

Bash や Python などの一部のプログラミング言語は、マシンコードにコンパイルできません。代わりに、言語インタープリターまたは言語仮想マシンが、事前の変換を行わずにプログラムのソースコードを逐次実行します。

インタープリター言語で書かれたソフトウェアは、そのまま解釈することも、バイトコンパイルすることもできます。

RPM を使用してソフトウェアをビルドおよびパッケージ化する方法は、これら 2 つのソフトウェアタイプで異なることに注意してください。

次のいずれかの方法を使用して、コンパイル言語で書かれたソフトウェアを実行可能ファイルにビルドできます。

次のセクションでは、手動 または 自動 ビルドを使用して、C プログラミング言語で記述された Hello World プログラムをビルドする方法を説明します。

#include <stdio.h>

int main(void) {
    printf("Hello World\n");
    return 0;
}

次のいずれかの方法を使用して、インタープリター型プログラミング言語で記述されたソースコードをマシンコードに変換できます。

次のセクションでは、Python で書かれた Hello World プログラムをバイトコンパイル する方法と、Bash で書かれた Hello World プログラムをそのまま解釈 する方法を説明します。

print("Hello World")

#!/bin/bash

printf "Hello World\n"

diff ユーティリティーを使用して、元のソースコードからパッチを作成できます。

patch ユーティリティーを使用してソフトウェアにパッチを適用できます。

bello プロジェクトは、Bash で Hello World を実装しています。この実装には bello シェルスクリプトのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルのほかにファイルが 1 つだけ含まれます。

pello プロジェクトは、Python で Hello World を実装しています。この実装には pello.py プログラムのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルのほかにファイルが 1 つだけ含まれます。

cello プロジェクトは、C で Hello World を実装しています。この実装には cello.c と Makefile ファイルのみが含まれています。したがって、作成される tar.gz アーカイブには、LICENSE ファイルに加えて 2 つのファイルが含まれます。

以下の表では、RPM SPEC ファイルの Preamble セクションで頻繁に使用されるディレクティブの一部を示しています。

Name のディレクティブ、Version のディレクティブ、および Release のディレクティブは、RPM パッケージのファイル名から設定されます。RPM パッケージの担当者やシステム管理者は、これら 3 つのディレクティブを N-V-R または NVR と呼びます。これは、RPM パッケージのファイル名に NAME-VERSION-RELEASE 形式が含まれるためです。

以下の例は、rpm コマンドを実行して、特定のパッケージの NVR 情報を取得する方法を示しています。

# rpm -q bash
bash-4.4.19-7.el8.x86_64

ここでは、bash がパッケージ名で、4.4.19 がバージョン番号を示し、7.el8 がリリースを意味しています。最後のマーカーの x86_64 は、アーキテクチャーを意味しています。NVR とは異なり、アーキテクチャーのマーカーは RPM パッケージャーで直接管理されていませんが、rpmbuild ビルド環境で定義されます。ただし、これはアーキテクチャーに依存しない noarch パッケージです。

RPM SPEC ファイルの Body section で使用される項目は次のとおりです。

SPEC ファイルには、Scriptlets や Triggers などの高度な項目を追加することもできます。

これは、ビルドプロセスではなく、エンドユーザーのシステムのインストールプロセスのさまざまな地点で有効になります。

rpmdev-newspec ユーティリティーを使用して Hello World! の 3 つの実装それぞれに SPEC ファイルを作成するには、次の手順を実行します。

RPM パッケージを作成するために rpmdev-newspec ユーティリティーによって提供される出力 SPEC ファイルを変更するには、次の手順を実行します。

これで、必要なプログラム用に SPEC ファイル全体を作成できるようになりました。

以下に示す、bash で書かれた bello プログラムの SPEC ファイルの例を参考として使用できます。

Name:           bello
Version:        0.1
Release:        1%{?dist}
Summary:        Hello World example implemented in bash script

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in
bash script.

%prep
%setup -q

%build

%install

mkdir -p %{buildroot}/%{_bindir}

install -m 0755 %{name} %{buildroot}/%{_bindir}/%{name}

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1-1
- First bello package
- Example second item in the changelog for version-release 0.1-1

以下に示す、Python プログラミング言語で書かれた pello プログラムの SPEC ファイルの例を参考として使用できます。

Name:           pello
Version:        0.1.1
Release:        1%{?dist}
Summary:        Hello World example implemented in Python

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

BuildRequires:  python
Requires:       python
Requires:       bash

BuildArch:      noarch

%description
The long-tail description for our Hello World Example implemented in Python.

%prep
%setup -q

%build

python -m compileall %{name}.py

%install

mkdir -p %{buildroot}/%{_bindir}
mkdir -p %{buildroot}/usr/lib/%{name}

cat > %{buildroot}/%{_bindir}/%{name} <<EOF
#!/bin/bash
/usr/bin/python /usr/lib/%{name}/%{name}.pyc
EOF

chmod 0755 %{buildroot}/%{_bindir}/%{name}

install -m 0644 %{name}.py* %{buildroot}/usr/lib/%{name}/

%files
%license LICENSE
%dir /usr/lib/%{name}/
%{_bindir}/%{name}
/usr/lib/%{name}/%{name}.py*

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 0.1.1-1
  - First pello package

pello をインストールするには、ラッパースクリプトを作成する必要があります。これは、シバンがバイトコンパイル言語で該当しないためです。このスクリプトは、次のいずれかの方法で作成できます。

この例では、SPEC ファイルにラッパースクリプトのインラインを作成し、SPEC ファイル自体がスクリプト可能であるこを示しています。このラッパースクリプトは、こちら のドキュメントを使用して Python バイトコンパイルコードを実行します。

この例の %install セクションは、アクセスできるように、バイトコンパイルファイルをシステム上のライブラリーディレクトリーにインストールする必要があるという事実に一致します。

以下に示す、C プログラミング言語で書かれた cello プログラムの SPEC ファイルの例を参考として使用できます。

Name:           cello
Version:        1.0
Release:        1%{?dist}
Summary:        Hello World example implemented in C

License:        GPLv3+
URL:            https://www.example.com/%{name}
Source0:        https://www.example.com/%{name}/releases/%{name}-%{version}.tar.gz

Patch0:         cello-output-first-patch.patch

BuildRequires:  gcc
BuildRequires:  make

%description
The long-tail description for our Hello World Example implemented in
C.

%prep
%setup -q

%patch0

%build
make %{?_smp_mflags}

%install
%make_install

%files
%license LICENSE
%{_bindir}/%{name}

%changelog
* Tue May 31 2016 Adam Miller <maxamillion@fedoraproject.org> - 1.0-1
- First cello package

cello プログラムは、rpmdev-newspec コマンドで提供される %make_install マクロを使用してインストールできます。これは、cello プログラムの Makefile が利用できるため可能です。

ソース RPM をビルドするには、次の手順を実行します。

ソース RPM (SRPM) からバイナリー RPM を再ビルドするには、次の手順を実行します。

バイナリー RPM の作成時に生成される出力は詳細なもので、これはデバッグに役立ちます。この出力は各種例によって異なり、SPEC ファイルに一致します。

生成されるバイナリー RPM は 、~/rpmbuild/RPMS/YOURARCH ディレクトリー (YOURARCH はアーキテクチャー) に配置されます。パッケージがアーキテクチャー固有でない場合は ~/rpmbuild/RPMS/noarch/ ディレクトリーに配置されます。

bello、pello、および cello バイナリー RPM を SPEC ファイルからビルドするには、次の手順を実行します。

ソース RPM から任意の種類の RPM をビルドします。これを行うには、次の手順を実行します。

次のセクションでは、bello SPEC ファイルと bello バイナリー RPM を例に、RPM のサニティーチェックを行うときに発生する可能性のある警告とエラーを調べます。

$ rpmlint bello.spec
bello.spec: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/bello-0.1-1.el8.src.rpm
bello.src: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.src: W: invalid-url Source0: https://www.example.com/bello/releases/bello-0.1.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/bello-0.1-1.el8.noarch.rpm
bello.noarch: W: invalid-url URL: https://www.example.com/bello HTTP Error 404: Not Found
bello.noarch: W: no-documentation
bello.noarch: W: no-manual-page-for-binary bello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

次のセクションでは、pello SPEC ファイルと pello バイナリー RPM を例に、RPM のサニティーチェックを行うときに発生する可能性のある警告とエラーを調べます。

$ rpmlint pello.spec
pello.spec:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.spec:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.spec:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.spec:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.spec:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.spec: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 5 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/pello-0.1.2-1.el8.src.rpm
pello.src: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.src:30: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}
pello.src:34: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.pyc
pello.src:39: E: hardcoded-library-path in %{buildroot}/usr/lib/%{name}/
pello.src:43: E: hardcoded-library-path in /usr/lib/%{name}/
pello.src:45: E: hardcoded-library-path in /usr/lib/%{name}/%{name}.py*
pello.src: W: invalid-url Source0: https://www.example.com/pello/releases/pello-0.1.2.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 5 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/noarch/pello-0.1.2-1.el8.noarch.rpm
pello.noarch: W: invalid-url URL: https://www.example.com/pello HTTP Error 404: Not Found
pello.noarch: W: only-non-binary-in-usr-lib
pello.noarch: W: no-documentation
pello.noarch: E: non-executable-script /usr/lib/pello/pello.py 0644L /usr/bin/env
pello.noarch: W: no-manual-page-for-binary pello
1 packages and 0 specfiles checked; 1 errors, 4 warnings.

次のセクションでは、cello SPEC ファイルと cello バイナリー RPM を例に、RPM のサニティーチェックを行うときに発生する可能性のある警告とエラーを調べます。

$ rpmlint ~/rpmbuild/SPECS/cello.spec
/home/admiller/rpmbuild/SPECS/cello.spec: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
0 packages and 1 specfiles checked; 0 errors, 1 warnings.

$ rpmlint ~/rpmbuild/SRPMS/cello-1.0-1.el8.src.rpm
cello.src: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.src: W: invalid-url Source0: https://www.example.com/cello/releases/cello-1.0.tar.gz HTTP Error 404: Not Found
1 packages and 0 specfiles checked; 0 errors, 2 warnings.

$ rpmlint ~/rpmbuild/RPMS/x86_64/cello-1.0-1.el8.x86_64.rpm
cello.x86_64: W: invalid-url URL: https://www.example.com/cello HTTP Error 404: Not Found
cello.x86_64: W: no-documentation
cello.x86_64: W: no-manual-page-for-binary cello
1 packages and 0 specfiles checked; 0 errors, 3 warnings.

パッケージの署名に必要な GNU Privacy Guard (GPG) キーを作成するには、次の手順を使用します。

パッケージに署名するには、%_gpg_name RPM マクロを指定する必要があります。

以下の手順では、パッケージの署名に使用する RPM を設定する方法を説明します。

一般的に、パッケージは署名なしでビルドされます。署名はパッケージのリリース直前に追加されます。

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

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

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

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

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

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 マクロ:

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

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

rm -rf 'cello-1.0'

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

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

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

次の表は、SPEC ファイルの %files セクションに必要な高度な RPM マクロのリストを示しています。

Red Hat Enterprise Linux では、複数のビルトイン RPM マクロを提供しています。

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

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

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

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

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

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

%_smp_mflags -l3

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

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

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

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

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

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

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

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

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

以下の手順では、rpm コマンドと --no_scriptlet_name_ オプションを使用して、スクリプトレットの実行を無効にする方法を説明します。

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

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

1 つのパッケージアップグレードの実行順序と、既存の各 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 ファイルにあります。

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

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

%post -p /usr/bin/python3

%post -p <lua>

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

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

%if expression
…​
%endif

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

%if expression
…​
%else
…​
%endif

次の例は、%if RPM 条件の使用法を示しています。

%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 スクリプトから削除されます。

%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 マクロが再定義されます。

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

%ifarch i386 sparc
…​
%endif

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

%ifnarch alpha
…​
%endif

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

%ifos linux
…​
%endif

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

SPEC ファイルには、RPM のビルドに rpmbuild ユーティリティーを使用する命令が含まれています。命令は、一連のセクションに含まれています。SPEC ファイルには、セクションが定義されている 2 つの主要部分があります。

Python プロジェクトの RPM SPEC ファイルには、非 Python RPM SPEC ファイルと比較していくつかの詳細があります。特に注目すべきは、Python ライブラリーの RPM パッケージ名に、Python 3.6 の場合は python3、Python 3.8 の場合は python38、Python 3.9 の場合は python39、Python 3.11 の場合は python3.11 など、バージョンを判別する接頭辞を常に含める必要があります。

その他の詳細は、次の SPEC ファイルの python3-detox パッケージの例 に記載されています。その詳細の説明は、例の下に記載されている注意事項を参照してください。

%global modname detox                                                1

Name:           python3-detox                                        2
Version:        0.12
Release:        4%{?dist}
Summary:        Distributing activities of the tox tool
License:        MIT
URL:            https://pypi.io/project/detox
Source0:        https://pypi.io/packages/source/d/%{modname}/%{modname}-%{version}.tar.gz

BuildArch:      noarch

BuildRequires:  python36-devel                                       3
BuildRequires:  python3-setuptools
BuildRequires:  python36-rpm-macros
BuildRequires:  python3-six
BuildRequires:  python3-tox
BuildRequires:  python3-py
BuildRequires:  python3-eventlet

%?python_enable_dependency_generator                                 4

%description

Detox is the distributed version of the tox python testing tool. It makes efficient use of multiple CPUs by running all possible activities in parallel.
Detox has the same options and configuration that tox has, so after installation you can run it in the same way and with the same options that you use for tox.

    $ detox

%prep
%autosetup -n %{modname}-%{version}

%build
%py3_build                                                           5

%install
%py3_install

%check
%{__python3} setup.py test                                           6

%files -n python3-%{modname}
%doc CHANGELOG
%license LICENSE
%{_bindir}/detox
%{python3_sitelib}/%{modname}/
%{python3_sitelib}/%{modname}-%{version}*

%changelog
...

SPEC ファイルでは、値をハードコーディングするのではなく、以下の Python 3 RPM のマクロのテーブルで説明されているマクロを常に使用します。

マクロ名では、バージョンを指定しない python ではなく、python3 または python2 を使用してください。SPEC ファイルの BuildRequires セクションで特定の Python 3 バージョンを python36-rpm-macros、python38-rpm-macros、python39-rpm-macros、または python3.11-rpm-macros に設定します。

Python プロジェクトをパッケージ化する際、以下のディレクトリーが存在する場合は、作成される RPM に以下のディレクトリーが含まれていることを確認してください。

このディレクトリーから、RPM ビルドプロセスは自動的に仮想 pythonX.Ydist Provides (python3.6dist(detox) など) を生成します。この仮想 Provides は、%python_enable_dependency_generator マクロにより指定されるパッケージにより提供されます。

RPM ビルド時にビルドエラーが発生する Python スクリプト内のインタープリターディレクティブを変更します。

パッケージ化された Python スクリプトに Python 3.6 以外のバージョンが必要な場合は、上記のコマンドを調整して必要なバージョンを含めます。

デフォルトでは、/usr/bin/python3 の形式でのインタープリターディレクティブは、Red Hat Enterprise Linux のシステムツールに使用される platform-python パッケージから Python を参照するインタープリターディレクティブに置き換えられます。カスタムパッケージの /usr/bin/python3 インタープリターディレクティブを変更して、AppStream リポジトリーからインストールした特定バージョンの Python を参照できます。

%undefine __brp_mangle_shebangs

Ruby は、ダイナミックなインタープリター言語で、反映的なオブジェクト指向の汎用プログラミング言語です。

Ruby で書かれたプログラムは、特定の Ruby パッケージ形式を提供する RubyGems プロジェクトを使用してパッケージ化されます。

RubyGems で作成したパッケージは gems と呼ばれ、RPM に再パッケージ化することもできます。

RubyGems は、Ruby 独自のパッケージ形式を表します。ただし、RubyGems には RPM が必要とするメタデータと同様のものが含まれ、RubyGems から RPM への変換が可能になります。

Ruby Packaging Guidelines では、以下の方法で RubyGems パッケージを RPM に再パッケージ化できます。

RubyGems は、SPEC ファイル、パッケージ名、依存関係などの RPM と同様の用語を使用します。

残りの RHEL RPM ディストリビューションに合わせるには、RubyGems で作成したパッケージが以下の規則に従う必要があります。

RubyGems パッケージのソース RPM を作成するには、以下のファイルが必要です。

次のセクションでは、RubyGems が作成したパッケージから RPM パッケージを作成する方法を説明します。

%prep
%setup -q -n  %{gem_name}-%{version}

# Modify the gemspec if necessary
# Also apply patches to code if necessary
%patch0 -p1

%build
# Create the gem as gem install only works on a gem file
gem build ../%{gem_name}-%{version}.gemspec

# %%gem_install compiles any C extensions and installs the gem into ./%%gem_dir
# by default, so that we can move it into the buildroot in %%install
%gem_install

%install
mkdir -p %{buildroot}%{gem_dir}
cp -a ./%{gem_dir}/* %{buildroot}%{gem_dir}/

# If there were programs installed:
mkdir -p %{buildroot}%{_bindir}
cp -a ./%{_bindir}/* %{buildroot}%{_bindir}

# If there are C extensions, copy them to the extdir.
mkdir -p %{buildroot}%{gem_extdir_mri}
cp -a .%{gem_extdir_mri}/{gem.build_complete,*.so} %{buildroot}%{gem_extdir_mri}/

$ gem install gem2rpm

BuildRequires: で使用される Perl 関連のビルドの最も頻繁に発生する依存関係は、以下の通りです。

特定の Perl モジュールがビルド時に必要な場合は、以下の手順に従います。

パッケージを特定の Perl バージョンに限定するには、以下の手順に従います。

Red Hat は、完全に互換性がない複数の Perl インタープリターを提供しています。そのため、Perl モジュールを提供するすべてのパッケージは、ビルド時に使用されたものと同じ Perl インタープリターをランタイムで使用する必要があります。

これを確認するには、以下の手順に従います。

デフォルトでは、Weak 依存関係 は、通常の Requires: と同様に扱われます。一致するパッケージが YUM トランザクションに含まれます。パッケージの追加でとエラーが発生する場合、デフォルトでは YUM は依存関係を無視します。そのため、ユーザーは Weak 依存関係 により追加されるパッケージを除外したり、後で削除したりできます。

Weak 依存関係 の一般的なユースケースは、以下のとおりです。

Hints はデフォルトで、YUM で無視されます。これは、GUI ツールで使用することで、デフォルトでインストールされていないアドオンパッケージを利用できます。ただし、インストールされているパッケージと組み合わせることで役に立ちます。

パッケージの主なユースケースの要件には、Hints を使用しないでください。代わりに、このような要件を強固な依存関係または Weak 依存関係 に含めます。

依存関係の解決に関する通常のルールは、この機能の影響を受けないことに注意してください。たとえば、Weak 依存関係 は、古いバージョンのパッケージが強制的に選ばれるようにすることはできません。

依存関係に複数のプロバイダーがある場合は、必須となるパッケージで Suggests: を追加して、どのオプションが優先されるかについて依存関係リゾルバーにヒントを提供することができます。

メインパッケージおよび他のプロバイダーが、必要なパッケージにヒントを追加することが、より簡素化されたソリューションであるということに同意する場合にのみ Enhances: が使用されます。

Package A: Requires: mysql

Package mariadb: Provides: mysql

Package community-mysql: Provides: mysql

Suggests: mariadb to Package A.

Forward 依存関係 は Requires と同様に、インストールするパッケージに対して評価されます。最も一致するパッケージもインストールされます。

一般的には、Forward 依存関係 が優先されます。システムに追加された別のパッケージを取得する場合は、この依存関係をパッケージに追加します。

Backward 依存関係 の場合、一致するパッケージもインストールされていると、その依存関係を含むパッケージがインストールされます。

Backward 依存関係 は主に、そのプラグイン、アドオン、エクステンション機能をディストリビューションやその他サードパーティーパッケージにアタッチできるサードパーティーベンダー向けに設計されています。

ブール値は、常に括弧で囲まれています。

これは、通常の依存関係から構築されます。

RPM 4.13 では、以下のブール値演算子が導入されました。

RPM 4.14 では、以下のブール値演算子がさらに導入されています。

以下の例のように、オペランド自体をブール式として使用できます。

このような場合は、オペランドを括弧で囲む必要もあります。and と or 演算子を組み合わせて、括弧で囲った同じ 1 セットと同じ演算子を繰り返すことができます。

Requires: (pkgA or pkgB or pkgC)

Requires: (pkgA or (pkgB and pkgC))

Supplements: (foo and (lang-support-cz or lang-support-all))

Requires: (pkgA with capB) or (pkgB without capA)

Supplements: ((driverA and driverA-tools) unless driverB)

Recommends: myPkg-langCZ and (font1-langCZ or font2-langCZ) if langsupportCZ

ブール値の依存関係 を使用しても、通常の依存関係のセマンティックは変更されません。

ブール値の依存関係 が使用されている場合は、名前が一致するものをすべてチェックし、一致する名前のブール値をブール値演算子で集計します。

if 演算子もブール値を返します。これは、直感的に理解しやすいものです。ただし、以下の例では、if の直感的な使用が誤解を招く可能性がある場合を示しています。

Requires: (pkgA if pkgB)

Conflicts: (pkgA if pkgB)

Conflicts: (pkgA and pkgB)

Requires: ((pkgA if pkgB) or pkgC or pkg)

Requires: ((pkgA and pkgB) or pkgC or pkg)

ファイルトリガー の構文は以下のとおりです。

%file_trigger_tag [FILE_TRIGGER_OPTIONS] — PATHPREFIX…​
body_of_script

詳細は以下のようになります。

file_trigger_tag は、ファイルトリガーのタイプを定義します。使用可能なタイプは次のとおりです。

FILE_TRIGGER_OPTIONS は、-P オプションを除き、RPM スクリプトレットオプションと同じ目的で使用されます。

トリガーの優先度は数字で定義されます。この数字が大きいほど、ファイルトリガースクリプトの実行優先度が高くなります。優先度が 100000 を超えるトリガーは、標準のスクリプトレットの前に実行され、その他のトリガーは標準のスクリプトレットの後に実行されます。デフォルトの優先度は 1000000 に設定されています。

各タイプのすべてのファイルトリガーには、1 つ以上のパス接頭辞とスクリプトが含まれている必要があります。

次の例は、File triggers の構文を示しています。

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
/usr/sbin/ldconfig

このファイルトリガーは、/usr/lib または /lib で始まるパスを含むパッケージのインストール後に、/usr/bin/ldconfig を直接実行します。/usr/lib または /lib で始まるパスを持つ複数のファイルがパッケージに含まれている場合でも、ファイルトリガーは 1 度のみ実行されます。ただし、/usr/lib または /lib で始まるファイル名はすべて、以下のようにスクリプト内でフィルタリングできるように、トリガースクリプトの標準入力に渡されます。

%filetriggerin — /lib, /lib64, /usr/lib, /usr/lib64
grep "foo" && /usr/sbin/ldconfig

このファイルトリガーは、/usr/lib で始まり、foo を同時に含むファイルがある各パッケージに対して /usr/bin/ldconfig を実行します。接頭辞に一致するファイルには、通常のファイル、ディレクトリー、シンボリックリンクなど、すべての種類のファイルが含まれることに注意してください。

ファイルトリガー には、以下の 2 つの主要タイプがあります。

ファイルトリガー は、以下のように、実行時間に基づいてさらに分割されます。

次の例は、glibc パッケージ内での File triggers の実際の使用法を示しています。

RHEL 8 では、インストールまたはアンインストールトランザクションの最後に ldconfig コマンドを呼び出すために、ファイルトリガー が glibc に実装されています。

これは、glibc SPEC ファイルに以下のスクリプトレットを含めることで実現されました。

%transfiletriggerin common -P 2000000 – /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end
%transfiletriggerpostun common -P 2000000 – /lib /usr/lib /lib64 /usr/lib64
/sbin/ldconfig
%end

そのため、複数のパッケージのインストールまたはアンインストールを行うと、トランザクション全体が終了してから、インストールしたすべてのライブラリーに対して ldconfig キャッシュが更新されます。そのため、個別のパッケージの RPM SPEC ファイルに ldconfig を呼び出すスクリプトレットを含める必要はありません。これにより、RHEL 7 に比べてパフォーマンスが改善され、各パッケージに対してキャッシュが別途更新されるようになりました。

64 ビットバージョンとそれ以前の 32 ビットバージョンには、複数の RPM タグがあります。64 ビットバージョンの名前の前には LONG 文字列があることに注意してください。

LONG 拡張機能は、コマンドラインで常に有効になります。rpm -q --QF コマンドを含むスクリプトを以前使用していた場合は、これらのタグ名に long を追加できます。

rpm -qp --qf="[%{filenames} %{longfilesizes}\n]"