2.10. Converting a Conventional Spec File

This section discusses converting a conventional spec file into a Software Collection spec file so that the converted spec file can be used in both the conventional package and the Software Collection.

2.10.1. Example of the Converted Spec File

To see what the diff file comparing a conventional spec file with a converted spec file looks like, refer to the following example: 
--- a/less.spec
+++ b/less.spec
@@ -1,10 +1,14 @@
+%{?scl:%global _scl_prefix /opt/provider}
+%{?scl:%scl_package less}
+%{!?scl:%global pkg_name %{name}}
+
 Summary: A text file browser similar to more, but better
-Name: less
+Name: %{?scl_prefix}less
 Version: 444
 Release: 7%{?dist}
 License: GPLv3+
 Group: Applications/Text
-Source: http://www.greenwoodsoftware.com/less/%{name}-%{version}.tar.gz
+Source: http://www.greenwoodsoftware.com/less/%{pkg_name}-%{version}.tar.gz
 Source1: lesspipe.sh
 Source2: less.sh
 Source3: less.csh
@@ -19,6 +22,7 @@ URL: http://www.greenwoodsoftware.com/less/
 Requires: groff
 BuildRequires: ncurses-devel
 BuildRequires: autoconf automake libtool
-Obsoletes: lesspipe < 1.0
+Obsoletes: %{?scl_prefix}lesspipe < 1.0
+%{?scl:Requires: %scl_runtime}
 
 %description
 The less utility is a text file browser that resembles more, but has
@@ -31,7 +35,7 @@ You should install less because it is a basic utility for viewing text
 files, and you'll use it frequently.
 
 %prep
-%setup -q
+%setup -q -n %{pkg_name}-%{version}
 %patch1 -p1 -b .Foption
 %patch2 -p1 -b .search
 %patch4 -p1 -b .time
@@ -51,16 +55,16 @@ make CC="gcc $RPM_OPT_FLAGS -D_GNU_SOURCE -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOU
 %install
 rm -rf $RPM_BUILD_ROOT
 make DESTDIR=$RPM_BUILD_ROOT install
-mkdir -p $RPM_BUILD_ROOT/etc/profile.d
+mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
 install -p -c -m 755 %{SOURCE1} $RPM_BUILD_ROOT/%{_bindir}
-install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT/etc/profile.d
-install -p -c -m 644 %{SOURCE3} $RPM_BUILD_ROOT/etc/profile.d
-ls -la $RPM_BUILD_ROOT/etc/profile.d
+install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
+install -p -c -m 644 %{SOURCE3} $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
+ls -la $RPM_BUILD_ROOT%{_sysconfdir}/profile.d
 
 %files
 %defattr(-,root,root,-)
 %doc LICENSE
-/etc/profile.d/*
+%{_sysconfdir}/profile.d/*
 %{_bindir}/*
 %{_mandir}/man1/*

2.10.2. Converting Tags and Macro Definitions

The following steps show how to convert tags and macro definitions in a conventional spec file into a Software Collection spec file.

Procedure 2.1. Converting tags and macro definitions

  1. You can change the location of the root directory by defining the %_scl_prefix macro above the %scl_package macro: 
    %{?scl:%global _scl_prefix /opt/provider}
  2. 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}
  3. You are advised to define the %pkg_name macro in the spec file preamble 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.
  4. Change the Name tag in the spec file preamble as follows: 
    Name: %{?scl_prefix}package_name
  5. 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.
  6. 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}
  7. 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
  8. Prefix the Provides tag with %{?scl_prefix}, as in the following example: 
    Provides: %{?scl_prefix}more

2.10.3. Converting Subpackages

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
Prefixing applies not only to the %package macro, but also for %description and %files. For example: 
%description -n %{?scl_prefix}rubygems
RubyGems is the Ruby standard for publishing and managing third party
libraries.
In case the subpackage requires the main package, make sure to also adjust the Requires tag in that subpackage so that the tag uses %{?scl_prefix}%{pkg_name}. For example: 
Requires: %{?scl_prefix}%{pkg_name} = %{version}-%{release}

2.10.4. Converting RPM Scripts

This section describes general rules for converting RPM scripts that can often be found in the %prep, %build, %install, %check, %pre, and %post sections of a conventional spec file.
  • Replace all occurrences of %name with %pkg_name. Most importantly, this includes adjusting the %setup macro.
    • Adjust 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.
  • If you are using any of the %_root_ macros to point to the system file system hierarchy, you must use conditionals for these macros so that you can then use the spec file for building both the conventional package and the Software Collection. Edit the macros as in the following example: 
    mkdir -p %{?scl:%_root_sysconfdir}%{?!scl:%_sysconfdir}
  • When building Software Collection packages that depend on other Software Collection packages, it is often important to ensure that the scl enable functionality links properly or run proper binaries, and so on. One of the examples where this is needed is compiling against a Software Collection library or running an interpreted script with the interpreter in the Software Collection.
    Wrap the script using the %{?scl: prefix, as in the following example: 
    %{?scl:scl enable %scl - << \EOF}
 set -e
 ruby example.rb
 RUBYOPT="-Ilib" ruby bar.rb
 # The rest of the script contents goes here.
%{?scl:EOF}
    It is important to specify set -e in the script so that the script behavior is consistent regardless of whether the script is executed in the rpm shell or the scl environment.
  • Pay attention to any scripts that are executed during the Software Collection package installation, such as:
    • %pretrans, %pre,
    • %post, %postun, %posttrans,
    • %triggerin, %triggerun, and %triggerpostun.
    If you use the scl enable functionality in those scripts, you are advised to start with an empty environment to avoid any unintentional collisions with the base system installation.
    To do so, use env -i - before enabling the Software Collection, as in the following example: 
    %posttrans
%{?scl:env -i - scl enable %{scl} - << \EOF}
%vagrant_plugin_register %{vagrant_plugin_name}
%{?scl:EOF}
  • All hardcoded paths found in RPM scripts must be replaced with proper macros. For example, replace all occurrences of /usr/share with %{_datadir}. This is needed because the $RPM_BUILD_ROOT variable and the %{build_root} macro are not relocated by the scl macro.

2.10.5. Software Collection Automatic Provides and Requires and Filtering Support

Important

The functionality described in this section is not available in Red Hat Enterprise Linux 6.
RPM in Red Hat Enterprise Linux 7 features support for automatic Provides and Requires and filtering. For example, for all Python libraries, RPM automatically adds the following Requires: 
Requires: python(abi) = (version)
As explained in Section 2.10, “Converting a Conventional Spec File”, you should prefix this Requires with %{?scl_prefix} when converting your conventional RPM package: 
Requires: %{?scl_prefix}python(abi) = (version))
Keep in mind that the scripts searching for these dependencies must sometimes be rewritten for your Software Collection, as the original RPM scripts are not extensible enough, and, in some cases, filtering is not usable. For example, to rewrite automatic Python Provides and Requires, add the following lines in the macros.%{scl}-config macro file: 
%__python_provides /usr/lib/rpm/pythondeps-scl.sh --provides %{_scl_root} %{scl_prefix}
%__python_requires /usr/lib/rpm/pythondeps-scl.sh --requires %{_scl_root} %{scl_prefix}
The /usr/lib/rpm/pythondeps-scl.sh file is based on a pythondeps.sh file from the conventional package and adjusts search paths.
If there are Provides or Requires that you need to adjust, for example, a pkg_config Provides, there are two ways to do it:
  • Add the following lines in the macros.%{scl}-config macro file so that it applies to all packages in the Software Collection: 
    %_use_internal_dependency_generator 0
%__deploop() while read FILE; do /usr/lib/rpm/rpmdeps -%{1} ${FILE}; done | /bin/sort -u
%__find_provides /bin/sh -c "%{?__filter_prov_cmd} %{__deploop P} %{?__filter_from_prov}"
%__find_requires /bin/sh -c "%{?__filter_req_cmd}  %{__deploop R} %{?__filter_from_req}"

# Handle pkgconfig's virtual Provides and Requires
%__filter_from_req | %{__sed} -e 's|pkgconfig|%{?scl_prefix}pkgconfig|g'
%__filter_from_prov | %{__sed} -e 's|pkgconfig|%{?scl_prefix}pkgconfig|g'
  • Or, alternatively, add the following lines after tag definitions in every spec file for which you want to filter Provides or Requires: 
    %{?scl:%filter_from_provides s|pkgconfig|%{?scl_prefix}pkgconfig|g}
%{?scl:%filter_from_requires s|pkgconfig|%{?scl_prefix}pkgconfig|g}
%{?scl:%filter_setup}

Important

When using filters, you need to pay attention to the automatic dependencies you change. For example, if the conventional package contains Requires: pkgconfig(package_1) and Requires: pkgconfig(package_2), and only package_2 is included in the Software Collection, ensure that you do not filter the Requires tag for package_1.

2.10.6. Software Collection Macro Files Support

In some cases, you may need to ship macro files with your Software Collection packages. They are located in the %{?scl:%{_root_sysconfdir}}%{!?scl:%{_sysconfdir}}/rpm/ directory, which corresponds to the /etc/rpm/ directory for conventional packages. When shipping macro files, ensure that:
  • You rename the macro files by appending .%{scl} to their names so that they do not conflict with the files from the base system installation.
  • The macros in the macro files are either not expanded, or they are using conditionals, as in the following example: 
    %__python2 %{_bindir}/python
%python2_sitelib %(%{?scl:scl enable %scl '}%{__python2} -c "from distutils.sysconfig import get_python_lib; print(get_python_lib())"%{?scl:'})
As another example, there may be a situation where you need to create a Software Collection mypython that depends on a Software Collection python26. The python26 Software Collection defines the %{__python2} macro as in the above sample. This macro will evaluate to /opt/provider/mypython/root/usr/bin/python2, but the python2 binary is only available in the python26 Software Collection (/opt/provider/python26/root/usr/bin/python2).
To be able to build software in the mypython Software Collection environment, ensure that:
  • The macros.python.python26 macro file, which is a part of the python26-python-devel package, contains the following line: 
    %__python26_python2 /opt/provider/python26/root/usr/bin/python2
  • And the macro file in the python26-build subpackage, and also the build subpackage in any depending Software Collection, contains the following line: 
    %scl_package_override() {%global __python2 %__python26_python2}
This will redefine the %{__python2} macro only if the build subpackage from a corresponding Software Collection is present, which usually means that you want to build software for that Software Collection.

2.10.7. Software Collection Shebang Support

A shebang is a sequence of characters at the beginning of a script that is used as an interpreter directive. The shebang is processed by the automatic dependency generator and it points to a certain location, possibly in the system root file system.
When the automatic dependency generator processes the shebang, it adds dependencies according to the interpreters they point to. From the Software Collection point of view, there are two types of shebangs:
#!/usr/bin/env example
This shebang instructs the /usr/bin/env program to run the interpreter.
The automatic dependency generator will create a dependency on the /usr/bin/env program, as expected.
If the $PATH environment variable is redefined properly in the enable scriptlet, the example interpreter is found in the Software Collection file system hierarchy, as expected.
You are advised to rewrite the shebang in your Software Collection package so that the shebang specifies the full path to the interpreter located in the Software Collection file system hierarchy.
#!/usr/bin/example
This shebang specifies the direct path to the interpreter.
The automatic dependency generator will create a dependency on the /usr/bin/example interpreter located outside the Software Collection file system hierarchy. However, when building a package for your Software Collection, you often want to create a dependency on the %{?_scl_root}/usr/bin/example interpreter located in the Software Collection file system hierarchy.
Keep in mind that even when you properly redefine the $PATH environment variable, this has no effect on what interpreter is used. The system version of the interpreter located outside the Software Collection file system hierarchy is always used. In most cases, this is not desired.
If you are using this type of shebang and you want the shebang to point to the Software Collection file system hierarchy when building your Software Collection package, use a command like the following: 
find %{buildroot} -type f | \
  xargs sed -i -e '1 s"^#!/usr/bin/example"#!%{?_scl_root}/usr/bin/example"'
where /usr/bin/example is the interpreter you want to use.

2.10.8. Making a Software Collection Depend on Another Software Collection

To make one Software Collection depend on a package from another Software Collection, you need to adjust the BuildRequires and Requires tags in the dependent Software Collection's spec file so that these tags properly define the dependency.
For example, to define dependencies on two Software Collections named software_collection_1 and software_collection_2, add the following three lines to your application's spec file: 
BuildRequires: scl-utils-build
Requires: %scl_require software_collection_1
Requires: %scl_require software_collection_2
Ensure that the spec file also contains the %scl_package macro in front of the spec file preamble, for example: 
%{?scl:%scl_package less}
Note that the %scl_package macro must be included in every spec file of your Software Collection.
You can also use the %scl_require_package macro to define dependencies on a particular package from a specific Software Collection, as in the following example: 
BuildRequires: scl-utils-build
Requires: %scl_require_package software_collection_1 package_name