このコンテンツは選択した言語では利用できません。
2.9. Converting a Conventional Spec File
The following steps show how to convert a conventional spec file into a Software Collection spec file so that the Software Collection spec file can be used in both the conventional package and the Software Collection.
Procedure 2.1. Converting a conventional spec file into a Software Collection spec file
- Add the
%scl_packagemacro to the spec file. Place the macro in front of the spec file preamble as follows:%{?scl:%scl_package package_name}%{?scl:%scl_package package_name}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - You are advised to define the
%pkg_namemacro in the spec file in case the package is not built for the Software Collection:%{!?scl:%global pkg_name %{name}}%{!?scl:%global pkg_name %{name}}Copy to Clipboard Copied! Toggle word wrap Toggle overflow Consequently, you can use the%pkg_namemacro to define the original name of the package wherever it is needed in the spec file that you can then use for building both the conventional package and the Software Collection. - Change the
Nametag in the spec file preamble as follows:Name: %{?scl_prefix}package_nameName: %{?scl_prefix}package_nameCopy to Clipboard Copied! Toggle word wrap Toggle overflow - If you are building or linking with other Software Collection packages, then prefix the names of those Software Collection packages in the
RequiresandBuildRequirestags with%{?scl_prefix}as follows:Requires: %{?scl_prefix}ifconfigRequires: %{?scl_prefix}ifconfigCopy to Clipboard Copied! Toggle word wrap Toggle overflow When depending on the system versions of packages, you should avoid using versionedRequiresorBuildRequires. If you need to depend on a package that could be updated by the system, consider including that package in your Software Collection, or remember to rebuild your Software Collection when the system package updates. - To check that all essential Software Collection's packages are dependencies of the main metapackage, add the following macro after the
BuildRequiresorRequirestags in the spec file:%{?scl:Requires: %scl_runtime}%{?scl:Requires: %scl_runtime}Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Prefix the
Obsoletes,ConflictsandBuildConflictstags with%{?scl_prefix}. This is to ensure that the Software Collection can be used to deploy new packages to older systems without having the packages specified, for example, byObsoleteremoved from the base system installation. For example:Obsoletes: %{?scl_prefix}lesspipe < 1.0Obsoletes: %{?scl_prefix}lesspipe < 1.0Copy to Clipboard Copied! Toggle word wrap Toggle overflow - Prefix the
Providestag with%{?scl_prefix}, as in the following example:Provides: %{?scl_prefix}moreProvides: %{?scl_prefix}moreCopy to Clipboard Copied! Toggle word wrap Toggle overflow - For any subpackages that define their name with the
-noption, prefix their name with%{?scl_prefix}, as in the following example:%package -n %{?scl_prefix}more%package -n %{?scl_prefix}moreCopy to Clipboard Copied! Toggle word wrap Toggle overflow - Add or edit the
%setupmacro in the%prepsection of the spec file so that the macro can deal with a different package name in the Software Collection environment:%setup -q -n %{pkg_name}-%{version}%setup -q -n %{pkg_name}-%{version}Copy to Clipboard Copied! Toggle word wrap Toggle overflow Note that the%setupmacro is required and that you must always use the macro with the-noption to successfully build your Software Collection.
Example of the Converted Spec File
To see what the diff file comparing a conventional spec file with a converted spec file looks like, refer to the following example: