Procedure 2.1. Converting a conventional spec file into a Software Collection spec file

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 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

8. For any subpackages that define their name with the -n option, prefix their name with %{?scl_prefix}, as in the following example:

   ​%package -n %{?scl_prefix}more

9. Add or edit the %setup macro in the %prep section 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}

   Note that the %setup macro is required and that you must always use the macro with the -n option to successfully build your Software Collection.

Procedure 3.2. Updating the PKG_CONFIG_PATH environment variable for %{_libdir}

1. To update the PKG_CONFIG_PATH environment variable for the %{_libdir} macro, create a custom script /etc/profile.d/name.sh. The script is preloaded when a shell is started on the system.
   For example, create the following file:

   %{?scl_prefix}pc-libdir.sh

2. Use the pc-libdir.sh short script that modifies the PKG_CONFIG_PATH variable to refer to your .pc files:

   export PKG_CONFIG_PATH=%{_libdir}/pkgconfig:/opt/provider/software_collection/path/to/your/pc_files

3. Add the file to your Software Collection package's spec file:

   ​SOURCE2: %{?scl_prefix}pc-libdir.sh

4. Install this file into the system /etc/profile.d/ directory by adjusting the %install section of the Software Collection package's spec file:

   ​%install
   ​install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/profile.d/

Procedure 3.3. Updating the PKG_CONFIG_PATH environment variable for %{_datadir}

1. To update the PKG_CONFIG_PATH environment variable for the %{_datadir} macro, create a custom script /etc/profile.d/name.sh. The script is preloaded when a shell is started on the system.
   For example, create the following file:

   %{?scl_prefix}pc-datadir.sh

2. Use the pc-datadir.sh short script that modifies the PKG_CONFIG_PATH variable to refer to your .pc files:

   export PKG_CONFIG_PATH=%{_datadir}/pkgconfig:/opt/provider/software_collection/path/to/your/pc_files

3. Add the file to your Software Collection package's spec file:

   ​SOURCE2: %{?scl_prefix}pc-datadir.sh

4. Install this file into the system /etc/profile.d/ directory by adjusting the %install section of the Software Collection package's spec file:

   ​%install
   ​install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/profile.d/

Procedure 3.4. Updating the MANPATH environment variable for the disabled Software Collection

1. To update the MANPATH environment variable, create a custom script /etc/profile.d/name.sh. The script is preloaded when a shell is started on the system.
   For example, create the following file:

   %{?scl_prefix}manpage.sh

2. Use the manpage.sh short script that modifies the MANPATH variable to refer to your man path directory:

   export MANPATH=/opt/provider/software_collection/path/to/your/man_pages:${MANPATH}

3. Add the file to your Software Collection package's spec file:

   ​SOURCE2: %{?scl_prefix}manpage.sh

4. Install this file into the system /etc/profile.d/ directory by adjusting the %install section of the Software Collection package's spec file:

   ​%install
   ​install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/profile.d/

Procedure 3.5. Running periodic tasks with cronjobs

1. To use cronjobs for running periodic tasks, place a crontab file for your Software Collection in the /etc/cron.d/ directory with the Software Collection's name.
   For example, create the following file:

   %{?scl_prefix}crontab

2. Ensure that the contents of the crontab file follow the standard crontab file format, as in the following example:

   0 1 * * Sun root scl enable software_collection '/opt/provider/software_collection/root/usr/bin/cron_job_name'

   where software_collection is the name of your Software Collection, and /opt/provider/software_collection/root/usr/bin/cron_job_name is the command you want to periodically run.
3. Add the file to your spec file of the Software Collection package:

   ​SOURCE2: %{?scl_prefix}crontab

4. Install the file into the system directory /etc/cron.d/ by adjusting the %install section of the Software Collection package's spec file:

   ​%install
   ​install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/cron.d/
   

Procedure 3.6. Managing log files with logrotate

1. To manage your log files with logrotate, place a custom logrotate file for your Software Collection in the system directory for the logrotate jobs /etc/logrotate.d/.
   For example, create the following file:

   %{?scl_prefix}logrotate

2. Ensure that the contents of the logrotate file follow the standard logrotate file format as follows:

   /opt/provider/software_collection/var/log/your_application_name.log {
         missingok
         notifempty
         size 30k
         yearly
         create 0600 root root
     }

3. Add the file to your spec file of the Software Collection package:

   ​SOURCE2: %{?scl_prefix}logrotate

4. Install the file into the system directory /etc/logrotate.d/ by adjusting the %install section of the Software Collection package's spec file:

   ​%install
   ​install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/logrotate.d/

Procedure 4.1. Providing your own scldevel subpackage

1. In your Software Collection's metapackage, add the scldevel subpackage by defining its name, summary, and description:

   ​%package scldevel
   ​Summary: Package shipping development files for %scl
   ​Provides: scldevel(%{scl_name_base})
   ​
   ​%description scldevel
   ​Package shipping development files, especially useful for development of
   ​packages depending on %scl Software Collection.

   You are advised to use the virtual Provides: scldevel(%{scl_name_base}) during the build of packages of dependent Software Collections. This will ensure availability of a version of the %{scl_name_base} Software Collection and its macros, as specified in the following step.
2. In the %install section of your Software Collection's metapackage, create the macros.%{scl_name_base}-scldevel file that is part of the scldevel subpackage and contains:

   ​cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF
   ​%%scl_%{scl_name_base} %{scl}
   ​%%scl_prefix_%{scl_name_base} %{scl_prefix}
   ​EOF

   Note that between all Software Collections that share the same %{scl_name_base} name, the provided macros.%{scl_name_base}-scldevel files must conflict. This is to disallow installing multiple versions of the %{scl_name_base} Software Collections. For example, in Red Hat Software Collections, the ruby193-scldevel subpackage cannot be installed when there is the ruby200-scldevel subpackage installed.