2.10. 従来の spec ファイルの変換
本項では、変換した spec ファイルが、従来のパッケージと Software Collection の両方で使用できるようにするため、従来の spec ファイルを Software Collection の spec ファイルに変換する方法を説明します。
2.10.1. 変換スペックファイルの例
従来の spec ファイルと変換された spec ファイルの比較は、以下の例を参照してください。
--- a/less.spec
+++ b/less.spec
@@ -1,10 +1,14 @@
+%{?scl:%global _scl_prefix /opt/provider}
+%{?scl:%scl_package less}
+%{!?scl:%global pkg_name %{name}}
+
Summary: A text file browser similar to more, but better
-Name: less
+Name: %{?scl_prefix}less
Version: 444
Release: 7%{?dist}
License: GPLv3+
Group: Applications/Text
-Source: http://www.greenwoodsoftware.com/less/%{name}-%{version}.tar.gz
+Source: http://www.greenwoodsoftware.com/less/%{pkg_name}-%{version}.tar.gz
Source1: lesspipe.sh
Source2: less.sh
Source3: less.csh
@@ -19,6 +22,7 @@ URL: http://www.greenwoodsoftware.com/less/
Requires: groff
BuildRequires: ncurses-devel
BuildRequires: autoconf automake libtool
-Obsoletes: lesspipe < 1.0
+Obsoletes: %{?scl_prefix}lesspipe < 1.0
+%{?scl:Requires: %scl_runtime}
%description
The less utility is a text file browser that resembles more, but has
@@ -31,7 +35,7 @@ You should install less because it is a basic utility for viewing text
files, and you'll use it frequently.
%prep
-%setup -q
+%setup -q -n %{pkg_name}-%{version}
%patch1 -p1 -b .Foption
%patch2 -p1 -b .search
%patch4 -p1 -b .time
@@ -51,16 +55,16 @@ make CC="gcc $RPM_OPT_FLAGS -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOU
%install
rm -rf $RPM_BUILD_ROOT
make DESTDIR=$RPM_BUILD_ROOT install
-mkdir -p $RPM_BUILD_ROOT/etc/profile.d
+mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
install -p -c -m 755 %{SOURCE1} $RPM_BUILD_ROOT/%{_bindir}
-install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT/etc/profile.d
-install -p -c -m 644 %{SOURCE3} $RPM_BUILD_ROOT/etc/profile.d
-ls -la $RPM_BUILD_ROOT/etc/profile.d
+install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
+install -p -c -m 644 %{SOURCE3} $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
+ls -la $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
%files
%defattr(-,root,root,-)
%doc LICENSE
-/etc/profile.d/*
+%{_sysconfdir}/profile.d/*
%{_bindir}/*
%{_mandir}/man1/*2.10.2. タグおよびマクロ定義の変換
以下の手順では、従来のスペックファイルのタグおよびマクロ定義を Software Collection の spec ファイルに変換する方法を説明します。
手順2.1 タグおよびマクロ定義の変換
%_scl_prefixの上に%scl_package macroマクロを定義することで、root ディレクトリーの場所を変更できます。%{?scl:%global _scl_prefix /opt/provider}%scl_packageマクロを spec ファイルに追加します。次のように、スペックファイルのプリアンブルの前にマクロを配置します。%{?scl:%scl_package package_name}- Software Collection 用にパッケージを構築していない場合は、spec ファイルのプリアンブルで
%pkg_nameマクロを定義することが推奨されます。%{!?scl:%global pkg_name %{name}}したがって、%pkg_nameマクロを使用して、従来のパッケージと Software Collection の両方を構築するのに使用できるスペックファイルで、パッケージの元の名前を定義することができます。 - spec ファイルの Preamble で
Nameタグを以下のように変更します。Name: %{?scl_prefix}package_name - 他の Software Collection パッケージを構築したり、リンクしたりする場合は、以下のように
RequiresタグおよびBuildRequiresタグにある パッケージの名前に%{?scl_prefix}を付けます。Requires: %{?scl_prefix}ifconfigパッケージのシステムバージョンによっては、バージョン管理RequiresまたはBuildRequiresを使用しないでください。システムで更新できるパッケージに依存する必要がある場合は、Software Collection にそのパッケージを含めるか、システムパッケージの更新時に Software Collection を再ビルドすることを忘れないようにしてください。 - Software Collection の基本的なパッケージがすべてメインのメタパッケージの依存関係であることを確認するには、spec ファイルの
BuildRequiresタグまたはRequiresタグの後に以下のマクロを追加します。%{?scl:Requires: %scl_runtime} Obsoletes、ConflictsおよびBuildConflictsタグの前に%{?scl_prefix}を付けます。これは、たとえば、ベースシステムのインストールからObsolete削除されるなどして、Software Collection を使用して、古いシステムに新しいパッケージをデプロイできるようにします。以下に例を示します。Obsoletes: %{?scl_prefix}lesspipe < 1.0- 以下の例のように、
Providesタグの前に%{?scl_prefix}を付けます。Provides: %{?scl_prefix}more
2.10.3. サブパッケージの変換
-n オプションで名前を定義するサブパッケージの場合は、以下の例のようにその名前の前に %{?scl_prefix} を付けます。
%package -n %{?scl_prefix}more
接頭辞は
%package マクロだけでなく、%description および %files に対しても適用されます。以下に例を示します。
%description -n %{?scl_prefix}rubygems
RubyGems is the Ruby standard for publishing and managing third party
libraries.
サブパッケージにメインパッケージが必要な場合は、タグが
%{?scl_prefix}%{pkg_name} を使用するようにサブパッケージの Requires タグも調整してください。以下に例を示します。
Requires: %{?scl_prefix}%{pkg_name} = %{version}-%{release}2.10.4. RPM スクリプトの変換
本セクションでは、従来の spec ファイルの
%prep、%build、%install、%check、%pre、および %post セクションで頻繁に検索できる RPM スクリプトを変換する一般的なルールを説明します。
%nameはすべて%pkg_nameに置き換えます。最も重要な点として、これには%setupマクロの調整が含まれます。- スペックファイルの
%prepセクションで%setupマクロを調整し、そのマクロが Software Collection 環境で異なるパッケージ名を処理できるようにします。%setup -q -n %{pkg_name}-%{version}%setupマクロが必要なため、Software Collection を正常に構築するには-nオプションとともにマクロを使用する必要があります。
%_root_マクロのいずれかを使用してシステムファイルシステム階層を参照する場合は、これらのマクロに条件を使用する必要があります。これにより、従来のパッケージと Software Collection の両方を構築するために spec ファイルを使用することができます。以下の例のようにマクロを編集します。mkdir -p %{?scl:%_root_sysconfdir}%{?!scl:%_sysconfdir}- 他の Software Collection パッケージに依存する Software Collection パッケージを構築する場合は、scl enable 機能リンクを正しく実行したり、適切なバイナリーを実行することが重要になることがよくあります。これが必要な例は、Software Collection ライブラリーに対してコンパイルするか、Software Collection でインタープリターを使用してインタープリターを実行する例です。以下の例のように、
%{?scl:接頭辞を使用してスクリプトをラップします。%{?scl:scl enable %scl - << \EOF} set -e ruby example.rb RUBYOPT="-Ilib" ruby bar.rb # The rest of the script contents goes here. %{?scl:EOF}スクリプトでset -eを指定することが重要です。これにより、スクリプトが rpm シェルまたは scl 環境で実行されるかどうかに関わらず、スクリプトの動作が一貫性を保つことが重要です。 - Software Collection パッケージのインストール時に実行されるスクリプトに注意してください。以下に例を示します。
%pretrans、%pre、%post、%postun、%posttrans、%triggerin、%triggerun、および%triggerpostun
このスクリプトの scl enable 機能を使用する場合は、ベースシステムのインストールとの意図しない競合を避けるために、空の環境から開始することが推奨されます。これを行うには、以下の例のように、Software Collection を有効にする前にenv -i -を使用します。%posttrans %{?scl:env -i - scl enable %{scl} - << \EOF} %vagrant_plugin_register %{vagrant_plugin_name} %{?scl:EOF} - RPM スクリプトで見つかったハードコーディングされたパスはすべて適切なマクロに置き換える必要があります。たとえば、すべての
/usr/shareを%{_datadir}で置き換えます。これは、$RPM_BUILD_ROOT変数と%{build_root}マクロがsclマクロで移動しないため、必要です 。
2.10.5. Software Collection の自動 Provides および Requires ならびにフィルタリングサポート
重要
このセクションで説明する機能は、Red Hat Enterprise Linux 6 では利用できません。
Red Hat Enterprise Linux 7 の RPM は
Provides、自動 Requires およびフィルタリングをサポートします。たとえば、すべての Python ライブラリーでは、RPM は自動的に以下の Requires を追加します。
Requires: python(abi) = (version)
Requires: %{?scl_prefix}python(abi) = (version))
元の RPM スクリプトは拡張できないため、これらの依存関係を検索するスクリプトを Software Collection に対して書き換える必要があるため、場合によってはフィルタリングを使用することができません。たとえば、Python の
Provides と Requires の自動書き込みを行い、macros.%{scl}-config マクロファイルに以下の行を追加します。
%__python_provides /usr/lib/rpm/pythondeps-scl.sh --provides %{_scl_root} %{scl_prefix}
%__python_requires /usr/lib/rpm/pythondeps-scl.sh --requires %{_scl_root} %{scl_prefix}/usr/lib/rpm/pythondeps-scl.sh ファイルは、従来のパッケージの pythondeps.sh ファイルをベースとしており、検索パスを調整します。
pkg_config Provides など、調整が必要な Provides または Requires がある場合には、2 つの方法があります。
- Software Collection のすべてのパッケージに適用されるように、
macros.%{scl}-configマクロファイルに次の行を追加します。%_use_internal_dependency_generator 0 %__deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE}; done | /bin/sort -u %__find_provides /bin/sh -c "%{?__filter_prov_cmd} %{__deploop P} %{?__filter_from_prov}" %__find_requires /bin/sh -c "%{?__filter_req_cmd} %{__deploop R} %{?__filter_from_req}" # Handle pkgconfig's virtual Provides and Requires %__filter_from_req | %{__sed} -e 's|pkgconfig|%{?scl_prefix}pkgconfig|g' %__filter_from_prov | %{__sed} -e 's|pkgconfig|%{?scl_prefix}pkgconfig|g' ProvidesまたはRequiresにフィルター処理を行うすべての spec ファイルのタグ定義の後に以下の行を追加します。%{?scl:%filter_from_provides s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_from_requires s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_setup}
重要
フィルターを使用する場合は、変更する自動依存関係に注意する必要があります。たとえば、従来のパッケージに含まれるのが
Requires: pkgconfig(package_1) および Requires: pkgconfig(package_2) であり、package_2 は Software Collection に含まれる場合は、package_1 の Requires タグにフィルターを適用しないようにしてください 。
2.10.6. Software Collection マクロファイルのサポート
場合によっては、Software Collection パッケージでマクロファイルを配信しないといけない場合があります。これらは
%{?scl:%{_root_sysconfdir}}%{!?scl:%{_sysconfdir}}/rpm/ ディレクトリーにあります。これは、従来のパッケージの /etc/rpm/ ディレクトリーに対応します。マクロファイルを読み込む際には、以下を確認します。
.%{scl}を名前に追加してマクロファイルの名前を変更する場合は、ベースシステムインストールのファイルと競合しないようにします。- マクロファイル内のマクロは、以下の例のように、拡張されていないか、条件を使用しているかのいずれかになります。
%__python2 %{_bindir}/python %python2_sitelib %(%{?scl:scl enable %scl '}%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"%{?scl:'})
別の例として、Software Collection python26 に依存する Software Collection mypython を作成する必要がある場合もあります。python26 Software Collection は上記のサンプルのように
%{__python2} マクロを定義します。このマクロは /opt/provider/mypython/root/usr/bin/python2 に評価されますが、python2 バイナリーは python26 Software Collection (/opt/provider/python26/root/usr/bin/python2) でのみ利用できます。
mypython Software Collection 環境でソフトウェアを構築するには、以下を確認します。
- python26-python-devel パッケージの一部である
macros.python.python26マクロファイルには、以下の行が含まれます。%__python26_python2 /opt/provider/python26/root/usr/bin/python2
- また、python26-build サブパッケージ内のマクロファイルと、Software Collection の build サブパッケージには、以下の行が含まれます。
%scl_package_override() {%global __python2 %__python26_python2}
これにより、対応する Software Collection のビルドサブパッケージが存在する場合にのみ
%{__python2} マクロが再定義されます。これは通常、その Software Collection のソフトウェアを構築することを意味します。
2.10.7. Software Collection シバンのサポート
シバンは、インタープリターディレクティブとして使用されるスクリプトの最初の文字のシーケンスです。シバンは自動依存関係ジェネレーターによって処理され、場合によってはシステムの root ファイルシステム内の特定の場所を参照します。
自動依存関係ジェネレーターがシバンを処理すると、それが参照するインタープリターに応じて依存関係が追加されます。Software Collection の観点からは、以下の 2 種類のシバンがあります。
#!/usr/bin/env example- このシバンは、
/usr/bin/envプログラムにインタープリターの実行を指示します。自動依存関係ジェネレーターは、予想通りに /usr/bin/env プログラムに依存関係を作成します。enableスクリプトレットで$PATH環境変数が適切に再定義された場合、example インタープリターは期待通りに Software Collection ファイルシステム階層にあります。Software Collection パッケージでシバンを書き直し、シバンが Software Collection ファイルシステム階層にあるインタープリターへの完全パスを指定することが推奨されます。 #!/usr/bin/example- このシバンはインタープリターへの直接パスを指定します。自動依存関係ジェネレーターは、Software Collection ファイルシステム階層外にある
/usr/bin/exampleインタープリターの依存関係を作成します。ただし、Software Collection のパッケージを構築する場合は、多くの場合、Software Collection ファイルシステム階層にある%{?_scl_root}/usr/bin/exampleインタープリターに依存します。$PATH環境変数を適切に再定義しても、インタープリターが使用されるものには影響しないことに注意してください。Software Collection ファイルシステム階層外にあるインタープリターのシステムバージョンは常に使用されます。大半の場合、これは望ましくありません。このタイプのシバンを使用していて、シバンが Software Collection パッケージの構築時に Software Collection ファイルシステム階層を参照するようにするには、以下のようなコマンドを使用します。find %{buildroot} -type f | \ xargs sed -i -e '1 s"^#!/usr/bin/example"#!%{?_scl_root}/usr/bin/example"'/usr/bin/example は、使用するインタープリターになります。
2.10.8. Software Collection を別の Software Collection に依存させる
Software Collection を別の Software Collection のパッケージに依存するようにするには、これらのタグが依存関係を適切に定義できるように、依存する Software Collection のスペックファイルの
BuildRequires タグおよび Requires タグを調整する必要があります。
たとえば、software_collection_1 と software_collection_2 という名前の 2 つの Software Collections の依存関係を定義するには、以下の 3 つの行をアプリケーションの spec ファイルに追加します。
BuildRequires: scl-utils-build Requires: %scl_require software_collection_1 Requires: %scl_require software_collection_2
以下のように、spec ファイルの Preamble の前に
%scl_package マクロも含まれていることを確認してください。
%{?scl:%scl_package less}%scl_package マクロは、Software Collection の spec ファイルに含める必要があることに注意してください。
%scl_require_package マクロを使用して、以下の例にあるように、特定の Software Collection から特定のパッケージの依存関係を定義することもできます。
BuildRequires: scl-utils-build Requires: %scl_require_package software_collection_1 package_name
