Chapter 4. Extending Red Hat Software Collections

This chapter describes extending some of the Software Collections that are part of the Red Hat Software Collections offering.

4.1. Providing an scldevel Subpackage

The purpose of an scldevel subpackage is to make the process of creating dependent Software Collections easier by providing a number of generic macro files. Packagers then use these macro files when they are extending existing Software Collections. scldevel is provided as a subpackage of your Software Collection's metapackage.
The following section describes creating an scldevel subpackage for two examples of Ruby Software Collections, ruby193 and ruby200.

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, the ruby193-scldevel subpackage cannot be installed when there is the ruby200-scldevel subpackage installed.

4.1.1. Using an scldevel Subpackage in a Dependent Software Collection

To use your scldevel subpackage in a Software Collection that depends on the ruby200 Software Collection, update the metapackage of the dependent Software Collection as described below.

Procedure 4.2. Using your own scldevel subpackage in a dependent Software Collection

  1. Consider adding the following at the beginning of the metapackage's spec file: 
    %{!?scl_ruby:%global scl_ruby ruby200}
%{!?scl_prefix_ruby:%global scl_prefix_ruby %{scl_ruby}-}
    These two lines are optional. They are only meant as a visual hint that the dependent Software Collection has been designed to depend on the ruby200 Software Collection. If there is no other scldevel subpackage available in the build root, then the ruby200-scldevel subpackage is used as a build requirement.
    You can substitute these lines with the following line: 
    %{?scl_prefix_ruby}
  2. Add the following build requirement to the metapackage: 
    BuildRequires: %{scl_prefix_ruby}scldevel
    By specifying this build requirement, you ensure that the scldevel subpackage is in the build root and that the default values are not in use. Omitting this package could result in broken requires at the subsequent packages' build time.
  3. Ensure that the %package runtime part of the metapackage's spec file includes the following lines: 
    %package runtime
Summary: Package that handles %scl Software Collection.
Requires: scl-utils
Requires: %{scl_prefix_ruby}runtime
  4. Ensure that the %package build part of the metapackage's spec file includes the following lines: 
    %package build
Summary: Package shipping basic build configuration
Requires: %{scl_prefix_ruby}scldevel
    Specifying Requires: %{scl_prefix_ruby}scldevel ensures that macros are available in all packages of the Software Collection.