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
- 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 virtualProvides: 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. - In the
%install
section of your Software Collection's metapackage, create themacros.%{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 providedmacros.%{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
- 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}
- 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. - 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
- 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
SpecifyingRequires: %{scl_prefix_ruby}scldevel
ensures that macros are available in all packages of the Software Collection.