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.

4.1.1. Creating an scldevel Subpackage

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.2. 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. Consider including the following lines in the %package build part of the metapackage's spec file:
    %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.
    Note that adding this Requires only makes sense in specific use cases, such as where packages in a dependent Software Collection use macros provided by the scldevel subpackage.