Procedure 2.1. Converting tags and macro definitions

1. Add the %scl_package macro to the spec file. Place the macro in front of the spec file preamble as follows:

   %{?scl:%scl_package package_name}

2. You are advised to define the %pkg_name macro in the spec file preamble in case the package is not built for the Software Collection:

   %{!?scl:%global pkg_name %{name}}

   Consequently, you can use the %pkg_name macro 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.
3. Change the Name tag in the spec file preamble as follows:

   Name: %{?scl_prefix}package_name

4. If you are building or linking with other Software Collection packages, then prefix the names of those Software Collection packages in the Requires and BuildRequires tags with %{?scl_prefix} as follows:

   Requires: %{?scl_prefix}ifconfig

   When depending on the system versions of packages, you should avoid using versioned Requires or BuildRequires. 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.
5. To check that all essential Software Collection's packages are dependencies of the main metapackage, add the following macro after the BuildRequires or Requires tags in the spec file:

   %{?scl:Requires: %scl_runtime}

6. Prefix the Obsoletes, Conflicts and BuildConflicts tags 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, by Obsolete removed from the base system installation. For example:

   Obsoletes: %{?scl_prefix}lesspipe < 1.0

7. Prefix the Provides tag with %{?scl_prefix}, as in the following example:

   Provides: %{?scl_prefix}more