Product SiteDocumentation Site

⁠Chapter 4. Extending Software Collections

4.1. Providing an scldevel Subpackage
4.1.1. Using an scldevel Subpackage in a Dependent Software Collection
This chapter describes extending Software Collections.

⁠4.1. Providing an scldevel Subpackage

Providing an scldevel subpackage in your Software Collection's metapackage can make it easier for users to create a dependent Software Collection. This section describes creating an scldevel subpackage for Ruby-based 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, in Red Hat Software Collections, 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 a Software Collection ruby200, 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.