Packaging Guide
A guide to packaging Software Collections for Red Hat Enterprise Linux
Abstract
Making open source more inclusive
Chapter 1. Introducing Software Collections
1.1. Why Package Software with RPM?
With RPM, you can:
- Install, reinstall, remove, upgrade and verify packages.
- Users can use standard package management tools (for example Yum or PackageKit) to install, reinstall, remove, upgrade and verify your RPM packages.
- Use a database of installed packages to query and verify packages.
- Because RPM maintains a database of installed packages and their files, users can easily query and verify packages on their system.
- Use metadata to describe packages, their installation instructions, and so on.
- Each RPM package includes metadata that describes the package's components, version, release, size, project URL, installation instructions, and so on.
- Package pristine software sources into source and binary packages.
- RPM allows you to take pristine software sources and package them into source and binary packages for your users. In source packages, you have the pristine sources along with any patches that were used, plus complete build instructions. This design eases the maintenance of the packages as new versions of your software are released.
- Add packages to Yum repositories.
- You can add your package to a Yum repository that enables clients to easily find and deploy your software.
- Digitally sign your packages.
- Using a GPG signing key, you can digitally sign your package so that users are able to verify the authenticity of the package.
1.2. What Are Software Collections?
Software Collections:
- Do not overwrite system files
- Software Collections are distributed as a set of several components, which provide their full functionality without overwriting system files.
- Are designed to avoid conflicts with system files
- Software Collections make use of a special file system hierarchy to avoid possible conflicts between a single Software Collection and the base system installation.
- Require no changes to the RPM package manager
- Software Collections require no changes to the RPM package manager present on the host system.
- Need only minor changes to the spec file
- To convert a conventional package to a single Software Collection, you only need to make minor changes to the package spec file.
- Allow you to build a conventional package and a Software Collection package with a single spec file
- With a single spec file, you can build both the conventional package and the Software Collection package.
- Uniquely name all included packages
- With Software Collection's namespace, all packages included in the Software Collection are uniquely named.
- Do not conflict with updated packages
- Software Collection's namespace ensures that updating packages on your system causes no conflicts.
- Can depend on other Software Collections
- Because one Software Collection can depend on another, you can define multiple levels of dependencies.
1.3. Enabling Support for Software Collections
#
yum install scl-utils scl-utils-build
Important
Optional
channel to install the scl-utils-build package.
1.4. Installing a Software Collection
software_collection_1
, run the following command:
#
yum install software_collection_1
1.5. Listing Installed Software Collections
scl --list
scl --list software_collection_1
1.6. Enabling a Software Collection
scl
action software_collection_1 software_collection_2 command
command
with multiple arguments, remember to enclose the command and its arguments in quotes:
scl
action software_collection_1 software_collection_2 'command --argument'
--
command separator to run a command
with multiple arguments:
scl
action software_collection_1 software_collection_2 -- command --argument
Remember that:
- When you run the scl tool, it creates a child process (subshell) of the current shell. Running the command again then creates a subshell of the subshell.
- You can list enabled Software Collections for the current subshell. See Section 1.7, “Listing Enabled Software Collections” for more information.
- You have to disable an enabled Software Collection first to be able to enable it again. To disable the Software Collection, exit the subshell created when enabling the Software Collections.
- When using the scl tool to enable a Software Collection, you can only perform one action with the enabled Software Collection at a time. The enabled Software Collection must be disabled first before performing another action.
1.6.1. Running an Application Directly
--version
option in the Software Collection named software_collection_1, execute the following command:
scl enable software_collection_1 'perl --version'
1.6.2. Running a Shell with Multiple Software Collections Enabled
scl enable software_collection_1 software_collection_2 bash
1.6.3. Running Commands Stored in a File
cat cmd | scl enable software_collection_1 -
cmd
file, in the environment of the Software Collection named software_collection_1.
1.7. Listing Enabled Software Collections
$X_SCLS
environment variable by running the following command:
echo $X_SCLS
1.8. Uninstalling a Software Collection
software_collection_1
, run the following command:
yum remove software_collection_1\*
yum remove
command to remove the scl utility.
Chapter 2. Packaging Software Collections
2.1. Creating Your Own Software Collections
- install all required Software Collections and packages manually and then deploy your application, or
- create a new Software Collection for your application.
When creating a new Software Collection for your application:
- Create a Software Collection metapackage
- Each Software Collection includes a metapackage, which installs a subset of the Software Collection's packages that are essential for the user to perform most common tasks with the Software Collection. See Section 2.7.1, “Metapackage” for more information on creating metapackages.
- Consider specifying the location of the Software Collection root directory
- You are advised to specify the location of the Software Collection root directory by setting the
%_scl_prefix
macro in the Software Collection spec file. For more information, see Section 2.3, “The Software Collection Root Directory”. - Consider prefixing the name of your Software Collection packages
- You are advised to prefix the name of your Software Collection packages with the vendor and Software Collection's name. For more information, see Section 2.4, “The Software Collection Prefix”.
- Specify all Software Collections and other packages required by your application as dependencies
- Ensure that all Software Collections and other packages required by your application are specified as dependencies of your Software Collection. For more information, see Section 2.10.8, “Making a Software Collection Depend on Another Software Collection”.
- Convert existing conventional packages or create new Software Collection packages
- Ensure that all macros in your Software Collection package spec files use conditionals. See Section 2.10, “Converting a Conventional Spec File” for more information on how to convert an existing package spec file.
- Build your Software Collection
- After you create the Software Collection metapackage and convert or create packages for your Software Collection, you can build the Software Collection with the rpmbuild utility. For more information, see Section 2.12, “Building a Software Collection”.
2.2. The File System Hierarchy
/opt/
directory to avoid possible conflicts between Software Collections and the base system installation. The use of the /opt/
directory is recommended by the Filesystem Hierarchy Standard (FHS).
Figure 2.1. The Software Collection File System Hierarchy
2.3. The Software Collection Root Directory
%_scl_prefix
macro in the spec file, as in the following example:
%global _scl_prefix /opt/provider
/opt/provider/prefix-application-version/
Note
_scl_prefix
macro above the %scl_package
macro in the spec file.
2.4. The Software Collection Prefix
- the provider part, which defines the provider's name, and
- the name of the Software Collection itself.
-
), as in the following example:
myorganization-ruby193
rh
as the provider's name. For example:
rh-ruby23
2.5. Software Collection Package Names
- the prefix part, discussed in Section 2.4, “The Software Collection Prefix”, and
- the name and version number of the application that is a part of the Software Collection.
-
), as in the following example:
myorganization-ruby193-foreman-1.1
2.6. Software Collection Scriptlets
/opt/provider/software_collection/
directory in your Software Collection package. If you only need to distribute a single scriptlet in your Software Collection, it is highly recommended that you use enable
as the name for that scriptlet. When the user runs a command in the Software Collection environment by executing scl enable software_collection command
, the /opt/provider/software_collection/enable
scriptlet is then used to update search paths, and so on.
scl enable
command. The subshell is only active for the time the command is being performed.
2.7. Package Layout
2.7.1. Metapackage
- The main package: %name
- The main package in the Software Collection contains dependencies of the base packages, which are included in the Software Collection. The main package does not contain any files.When specifying dependencies for your Software Collection's packages, ensure that no other package in your Software Collection depends on the main package. The purpose of the main package is to install only those packages that are essential for the user to perform most common tasks with the Software Collection.Normally, the main package does not specify any build time dependencies (for instance, packages that are only build time dependencies of another Software Collection's packages).For example, if the name of the Software Collection is
myorganization-ruby193
, then the main package macro is expanded to:myorganization-ruby193
- The runtime subpackage: %name-runtime
- The runtime subpackage in the Software Collection owns the Software Collection's file system and delivers the Software Collection's scriptlets. This package needs to be installed for the user to be able to use the Software Collection.For example, if the name of the Software Collection is
myorganization-ruby193
, then the runtime subpackage macro is expanded to:myorganization-ruby193-runtime
- The build subpackage: %name-build
- The build subpackage in the Software Collection delivers the Software Collection's build configuration. It contains RPM macros needed for building packages into the Software Collection. The build subpackage is optional and can be excluded from the Software Collection.For example, if the name of the Software Collection is
myorganization-ruby193
, then the build subpackage macro is expanded to:myorganization-ruby193-build
The contents of themyorganization-ruby193-build
subpackage are shown below:$
cat /etc/rpm/macros.ruby193-config
%scl myorganization-ruby193 - The syspaths subpackage: %name-syspaths
- The syspaths subpackage in the Software Collection provides an optional way to install convenient shell wrappers and symbolic links into the standard path, thus altering the base system installation, but making binary files in the Software Collection packages easier to use.For example, if the name of the Software Collection is
myorganization-ruby193
, then the syspaths subpackage macro is expanded to:myorganization-ruby193-syspaths
For more information about the syspaths subpackage, see Section 3.3, “Providing syspaths Subpackages”. - The scldevel subpackage: %name-scldevel
- The scldevel subpackage in the %name Software Collection contains development files, which are useful when developing packages of another Software Collection that depends on the %name Software Collection. The scldevel subpackage is optional and can be excluded from the %name Software Collection.For example, if the name of the Software Collection is
myorganization-ruby193
, then the scldevel subpackage macro is expanded to:myorganization-ruby193-scldevel
For more information about the scldevel subpackage, see Section 4.1, “Providing an scldevel Subpackage”.
2.7.2. Creating a Metapackage
When creating a new metapackage:
- Define the following macros at the top of the metapackage spec file, above the
%scl_package
macro:scl_name_prefix
that specifies the provider's name to be used as a prefix in your Software Collection's name, for example, myorganization-. This is different from_scl_prefix
, which specifies the root of your Software Collection but also uses the provider's name. See Section 2.4, “The Software Collection Prefix” for more information.scl_name_base
that specifies the base name of your Software Collection, for example, ruby.scl_name_version
that specifies the version of your Software Collection, for example, 193.
- You are advised to define a Software Collection macro
nfsmountable
that changes the location of configuration and state files and makes your Software Collection usable over NFS. For more information, see Section 3.1, “Using Software Collections over NFS”. - Consider specifying all packages in your Software Collection that are essential for the Software Collection run time as dependencies of the metapackage. That way you can ensure that the packages are installed with the Software Collection metapackage.
- You are advised to add
Requires: scl-utils-build
to the build subpackage. - You are not required to use conditionals for Software Collection-specific macros in the metapackage.
- Include any path redefinition that the packages in your Software Collection may require in the
enable
scriptlet.For information on commonly used path redefinitions, see Section 2.9, “Commonly Used Path Redefinitions”. - Always make sure that the metapackage contains the
%setup
macro in the%prep
section, otherwise building the Software Collection will fail. If you do not need to use a particular option with the%setup
macro, add the%setup -c -T
command to the%prep
section.This is because the%setup
macro defines and creates the%buildsubdir
directory, which is normally used for storing temporary files at build time. If you do not define%setup
in your Software Collection packages, files in the%buildsubdir
directory will be overwritten, causing the build to fail. - Add any macros you need to use to the
macros.%{scl}-config
file in the build subpackage.
Example of the Metapackage
%global scl_name_prefix myorganization- %global scl_name_base ruby %global scl_name_version 193 %global scl %{scl_name_prefix}%{scl_name_base}%{scl_name_version} # Optional but recommended: define nfsmountable %global nfsmountable 1 %global _scl_prefix /opt/myorganization %scl_package %scl Summary: Package that installs %scl Name: %scl_name Version: 1 Release: 1%{?dist} License: GPLv2+ Requires: %{scl_prefix}less BuildRequires: scl-utils-build %description This is the main package for %scl Software Collection. %package runtime Summary: Package that handles %scl Software Collection. Requires: scl-utils %description runtime Package shipping essential scripts to work with %scl Software Collection. %package build Summary: Package shipping basic build configuration Requires: scl-utils-build %description build Package shipping essential configuration macros to build %scl Software Collection. # This is only needed when you want to provide an optional scldevel subpackage %package scldevel Summary: Package shipping development files for %scl %description scldevel Package shipping development files, especially useful for development of packages depending on %scl Software Collection. %prep %setup -c -T %install %scl_install cat >> %{buildroot}%{_scl_scripts}/enable << EOF export PATH="%{_bindir}:%{_sbindir}\${PATH:+:\${PATH}}" export LD_LIBRARY_PATH="%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}}" export MANPATH="%{_mandir}:\${MANPATH:-}" export PKG_CONFIG_PATH="%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}}" EOF # This is only needed when you want to provide an optional scldevel subpackage cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF %%scl_%{scl_name_base} %{scl} %%scl_prefix_%{scl_name_base} %{scl_prefix} EOF # Install the generated man page mkdir -p %{buildroot}%{_mandir}/man7/ install -p -m 644 %{scl_name}.7 %{buildroot}%{_mandir}/man7/ %files %files runtime -f filelist %scl_files %files build %{_root_sysconfdir}/rpm/macros.%{scl}-config %files scldevel %{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel %changelog * Fri Aug 30 2013 John Doe <jdoe@example.com> 1-1 - Initial package
2.8. Software Collection Macros
scl
defines where to relocate the Software Collection's file structure. The relocated file structure is a file system used exclusively by the Software Collection.
%scl_package
macro defines files ownership for the Software Collection's metapackage and provides additional packaging macros to use in the Software Collection environment.
%{?scl:macro}
, as in the following example:
%{?scl:Requires: %scl_runtime}
%scl_runtime
macro is the value of the Requires
tag. Both the macro and the tag use the %{?scl:
prefix.
2.8.1. Macros Specific to a Software Collection
Macro
|
Description
|
Example value
|
---|---|---|
%scl_name
|
name of the Software Collection
| software_collection_1
|
%scl_prefix
|
name of the Software Collection with a dash appended at the end
| software_collection_1-
|
%pkg_name
|
name of the original package
| perl
|
%_scl_prefix
|
root of the Software Collection (not package's root)
| /opt/provider/
|
%_scl_scripts
|
location of Software Collection's scriptlets
| /opt/provider/software_collection_1/
|
%_scl_root
|
installation root (install-root) of the package
| /opt/provider/software_collection_1/root/
|
%scl_require_package software_collection_1 package_2
|
depend on a particular package from a specific Software Collection
| software_collection_1-package_2
|
2.8.2. Macros Not Specific to a Software Collection
_root
as a prefix.
Macro
|
Description
|
Relocated
|
Example value
|
---|---|---|---|
%_root_prefix
|
Software Collection's
%_prefix macro
|
no
| /usr/
|
%_root_exec_prefix
|
Software Collection's
%_exec_prefix macro
|
no
| /usr/
|
%_root_bindir
|
Software Collection's
%_bindir macro
|
no
| /usr/bin/
|
%_root_sbindir
|
Software Collection's
%_sbindir macro
|
no
| /usr/sbin/
|
%_root_datadir
|
Software Collection's
%_datadir macro
|
no
| /usr/share/
|
%_root_sysconfdir
|
Software Collection's
%_sysconfdir macro
|
no
| /etc/
|
%_root_libexecdir
|
Software Collection's
%_libexecdir macro
|
no
| /usr/libexec/
|
%_root_sharedstatedir
|
Software Collection's
%_sharedstatedir macro
|
no
| /usr/com/
|
%_root_localstatedir
|
Software Collection's
%_localstatedir macro
|
no
| /usr/var/
|
%_root_includedir
|
Software Collection's
%_includedir macro
|
no
| /usr/include/
|
%_root_infodir
|
Software Collection's
%_infodir macro
|
no
| /usr/share/info/
|
%_root_mandir
|
Software Collection's
%_mandir macro
|
no
| /usr/share/man/
|
%_root_initddir
|
Software Collection's
%_initddir macro
|
no
| /etc/rc.d/init.d/
|
%
_root_libdir
|
Software Collection's
%_libdir macro, this macro does not work if Software Collection's metapackage is platform-independent
|
no
| /usr/lib/
|
2.8.3. The nfsmountable Macro
nfsmountable
allows you to change values for the _sysconfdir
, _sharedstatedir
, and _localstatedir
macros so that your Software Collection can have its state files and configuration files located outside the Software Collection's /opt
file system hierarchy. This makes the files easier to manage and is also required when using your Software Collection over NFS.
nfsmountable
is optional but recommended. For more information, see Section 3.1, “Using Software Collections over NFS”.
2.9. Commonly Used Path Redefinitions
enable
scriptlet to set up the Software Collection environment. They are also used to specify the location of the Software Collection components in the Software Collection file system hierarchy.
enable
scriptlet depends on the packages you choose to include in your Software Collection. The environment variables normally follow this pattern:
$ENV_VAR=$SCL_ENV_VAR:$ENV_VAR
2.9.1. Language-specific Path Redefinitions
- GEM_PATH
- The
GEM_PATH
environment variable specifies the location of Ruby gems. As such, it is also used in those Software Collections that extend the rh-ruby23 Software Collection. For more information, see Section 4.3, “Extending the rh-ruby23 Software Collection”.Include the following in theenable
scriptlet to redefine the environment variable:export GEM_PATH="\${GEM_PATH:=%{gem_dir}:\`scl enable %{scl_ruby} -- ruby -e "print Gem.path.join(':')"\`}"
- GOPATH
- The
GOPATH
environment variable specifies the location of Go source and binary files. Include the following in theenable
scriptlet to redefine the environment variable:export GOPATH="%{gopath}\${GOPATH:+:\${GOPATH}}"
- JAVACONFDIRS
- The
JAVACONFDIRS
environment variable is used to specify the location of thejava.conf
configuration file. Include the following in theenable
scriptlet to redefine the environment variable:export JAVACONFDIRS="%{_sysconfdir}/java\${JAVACONFDIRS:+:}\${JAVACONFDIRS:-}"
- PERL5LIB
- The
PERL5LIB
environment variable is used to specify the location of custom Perl modules so that they can be installed with the%{?_scl_root}
prefix. Include the following in theenable
scriptlet to redefine the environment variable:export PERL5LIB="%{_scl_root}%{perl_vendorlib}\${PERL5LIB:+:\${PERL5LIB}}"
- PYTHONPATH
- The
PYTHONPATH
environment variable specifies the location of custom Python libraries. Include the following in theenable
scriptlet to redefine the environment variable:export PYTHONPATH="%{_scl_root}%{python_sitearch}:%{_scl_root}%{python_sitelib}\${PYTHONPATH:+:}\${PYTHONPATH:-}"
2.9.2. Other Path Redefinitions
- CPATH
- The
CPATH
environment variable specifies include paths for the GCC compiler to use. Include the following in theenable
scriptlet to redefine the environment variable:export CPATH="%{_includedir}\${CPATH:+:\${CPATH}}"
- INFOPATH
- The
INFOPATH
environment variable specifies directories that contain Info files. Include the following in theenable
scriptlet to redefine the environment variable:export INFOPATH="%{_infodir}\${INFOPATH:+:\${INFOPATH}}"
- LD_LIBRARY_PATH
- The
LD_LIBRARY_PATH
environment variable specifies the location of libraries. For more information, see Section 3.5, “Software Collection Library Support”.Include the following in theenable
scriptlet to redefine the environment variable:export LD_LIBRARY_PATH="%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}}"
- LIBRARY_PATH
- The
LIBRARY_PATH
environment variable specifies the location of special linker files or ordinary libraries for GCC to use. Include the following in theenable
scriptlet to redefine the environment variable:export LIBRARY_PATH="%{_libdir}\${LIBRARY_PATH:+:\${LIBRARY_PATH}}"
- MANPATH
- The
MANPATH
environment variable specifies the location of man pages. For more information, see Section 3.7, “Software Collection MANPATH Support”.Include the following in theenable
scriptlet to redefine the environment variable:export MANPATH="%{_mandir}:\${MANPATH:-}"
- PATH
- The
PATH
environment variable specifies the location of binary files. Include the following in theenable
scriptlet to redefine the environment variable:export PATH="%{_bindir}:%{_sbindir}\${PATH:+:\${PATH}}"
- PCP_DIR
- The
PCP_DIR
environment variable specifies the location of files and directories used by PCP. Include the following in theenable
scriptlet to redefine the environment variable:export PCP_DIR="%{_scl_root}"
- PKG_CONFIG_PATH
- The
PKG_CONFIG_PATH
environment variable specifies the location of.pc
files used by the pkg-config program. For more information, see Section 3.6, “Software Collection .pc Files Support”.Include the following in theenable
scriptlet to redefine the environment variable:export PKG_CONFIG_PATH="%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}}"
- XDG_CONFIG_DIRS
- The
XDG_CONFIG_DIRS
environment variable specifies the location of desktop configuration files according to the freedesktop.org specification. Include the following in theenable
scriptlet to redefine the environment variable:export XDG_CONFIG_DIRS="%{_sysconfdir}/xdg:\${XDG_CONFIG_DIRS:-/etc/xdg}"
- XDG_DATA_DIRS
- The
XDG_DATA_DIRS
environment variable specifies the location of desktop data files according to the freedesktop.org specification. It is used in some Software Collections to locate the Software Collection-specific scripts or to enable bash completion.Include the following in theenable
scriptlet to redefine the environment variable:export XDG_DATA_DIRS="%{_datadir}:\${XDG_DATA_DIRS:-/usr/local/share:%{_root_datadir}}"
2.10. Converting a Conventional Spec File
2.10.1. Example of the Converted Spec File
--- 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
Procedure 2.1. Converting tags and macro definitions
- 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}
- 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}
- 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. - Change the
Name
tag in the spec file preamble as follows:Name: %{?scl_prefix}package_name
- If you are building or linking with other Software Collection packages, then prefix the names of those Software Collection packages in the
Requires
andBuildRequires
tags with%{?scl_prefix}
as follows:Requires: %{?scl_prefix}ifconfig
When depending on the system versions of packages, you should avoid using versionedRequires
orBuildRequires
. 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. - To check that all essential Software Collection's packages are dependencies of the main metapackage, add the following macro after the
BuildRequires
orRequires
tags in the spec file:%{?scl:Requires: %scl_runtime}
- Prefix the
Obsoletes
,Conflicts
andBuildConflicts
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, byObsolete
removed from the base system installation. For example:Obsoletes: %{?scl_prefix}lesspipe < 1.0
- Prefix the
Provides
tag with%{?scl_prefix}
, as in the following example:Provides: %{?scl_prefix}more
2.10.3. Converting Subpackages
-n
option, prefix their name with %{?scl_prefix}
, as in the following example:
%package -n %{?scl_prefix}more
%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.
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
%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 specifyset -e
in the script so that the script behavior is consistent regardless of whether the script is executed in therpm
shell or thescl
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 thescl 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, useenv -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 thescl
macro.
2.10.5. Software Collection Automatic Provides and Requires and Filtering Support
Important
Provides
and Requires
and filtering. For example, for all Python libraries, RPM automatically adds the following Requires
:
Requires: python(abi) = (version)
Requires
with %{?scl_prefix}
when converting your conventional RPM package:
Requires: %{?scl_prefix}python(abi) = (version))
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}
/usr/lib/rpm/pythondeps-scl.sh
file is based on a pythondeps.sh
file from the conventional package and adjusts search paths.
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
orRequires
:%{?scl:%filter_from_provides s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_from_requires s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_setup}
Important
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
%{?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:'})
%{__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
).
- 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}
%{__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
#!/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 theenable
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
BuildRequires
and Requires
tags in the dependent Software Collection's spec file so that these tags properly define the dependency.
BuildRequires: scl-utils-build Requires: %scl_require software_collection_1 Requires: %scl_require software_collection_2
%scl_package
macro in front of the spec file preamble, for example:
%{?scl:%scl_package less}
%scl_package
macro must be included in every spec file of your Software Collection.
%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
2.11. Uninstalling All Software Collection Directories
yum remove
command does not uninstall directories provided by those Software Collection packages and subpackages that are removed after the Software Collection runtime subpackage is removed.
%scl_runtime
macro to the spec file of each of those packages and subpackages:
%{?scl:Requires: %scl_runtime}
2.12. Building a Software Collection
rpmbuild -ba package.spec --define 'scl name'
rpmbuild -ba package.spec
) is that you have to append the --define
option to the rpmbuild
command when building a Software Collection.
--define
option defines the scl
macro, which uses the Software Collection configured in the Software Collection spec file (package.spec
).
rpmbuild -ba package.spec
to build the Software Collection, specify the following in the package.spec
file:
BuildRequires: software_collection-build
2.12.1. Rebuilding a Software Collection without build Subpackages
rpmbuild -ba package.spec --define 'scl name'
command.
rpmbuild
command will fail.
2.12.2. Avoiding debuginfo File Conflicts
Source
tag, and thus unpack source files into the same directory underneath the %_builddir
directory, their debuginfo
packages will have file conflicts. Due to these conflicts, the user will be unable to install both packages on the same system at the same time.
%_builddir
directory. By doing so, the debuginfo
package generation script produces debuginfo
files that do not conflict with files from the other debuginfo
package.
--- a/tbb.spec +++ b/tbb.spec @@ -66,11 +66,13 @@ PDF documentation for the user of the Threading Building Block (TBB) C++ library. %prep -%setup -q -n %{sourcebasename} +%setup -q -c -n %{name} +cd %{sourcebasename} %patch1 -p1 %patch2 -p1 %build +cd %{sourcebasename} %{?scl:scl enable %{scl} - << \EOF} make %{?_smp_mflags} CXXFLAGS="$RPM_OPT_FLAGS" tbb_build_prefix=obj %{?scl:EOF} @@ -81,6 +83,7 @@ done %install rm -rf $RPM_BUILD_ROOT +cd %{sourcebasename} mkdir -p $RPM_BUILD_ROOT/%{_libdir} mkdir -p $RPM_BUILD_ROOT/%{_includedir} @@ -108,20 +111,20 @@ done %files %defattr(-,root,root,-) -%doc COPYING doc/Release_Notes.txt +%doc %{sourcebasename}/COPYING %{sourcebasename}/doc/Release_Notes.txt %{_libdir}/*.so.2 %files devel %defattr(-,root,root,-) -%doc CHANGES +%doc %{sourcebasename}/CHANGES %{_includedir}/tbb %{_libdir}/*.so %{_libdir}/pkgconfig/*.pc %files doc %defattr(-,root,root,-) -%doc doc/Release_Notes.txt -%doc doc/html +%doc %{sourcebasename}/doc/Release_Notes.txt +%doc %{sourcebasename}/doc/html %changelog * Wed Nov 13 2013 John Doe <jdoe@example.com> - 4.1-5.20130314
Chapter 3. Advanced Topics
3.1. Using Software Collections over NFS
nfsmountable
to use a Software Collection over NFS. If the macro is defined when building a Software Collection, the resulting Software Collection has its state files and configuration files located outside the Software Collection's /opt
file system hierarchy. This enables you to mount the /opt
file system hierarchy over NFS as read-only. It also makes state files and configuration files easier to manage.
nfsmountable
is optional but recommended.
nfsmountable
macro, ensure that the Software Collection metapackage spec file contains the following lines:
%global nfsmountable 1 %scl_package %scl
nfsmountable
macro must be defined before defining the %scl_package
macro. This is because the %scl_package
macro redefines the _sysconfdir
, _sharedstatedir
, and _localstatedir
macros depending on whether the nfsmountable
macro has been defined or not. The values that nfsmountable
changes for the redefined macros are detailed in the following table.
Macro
|
Original definition
|
Expanded value for the original definition
|
Changed definition
|
Expanded value for the changed definition
|
---|---|---|---|---|
_sysconfdir
|
%{_scl_root}/etc
|
/opt/provider/%{scl}/root/etc
|
%{_root_sysconfdir}%{_scl_prefix}/%{scl}
|
/etc/opt/provider/%{scl}
|
_sharedstatedir
|
%{_scl_root}/var/lib
|
/opt/provider/%{scl}/root/var/lib
|
%{_root_localstatedir}%{_scl_prefix}/%{scl}/lib
|
/var/opt/provider/%{scl}/lib
|
_localstatedir
|
%{_scl_root}/var
|
/opt/provider/%{scl}/root/var
|
%{_root_localstatedir}%{_scl_prefix}/%{scl}
|
/var/opt/provider/%{scl}
|
3.1.1. Changed Directory Structure and File Ownership
nfsmountable
macro also has an impact on how the scl_install
and scl_files
macros create a directory structure and set the file ownership when you run the rpmbuild
command.
nfsmountable
macro defined looks as follows:
$
rpmbuild -ba software_collection.spec --define 'scl software_collection'
...$
rpm -qlp software_collection-runtime-1-1.el6.x86_64
/etc/opt/provider/software_collection /etc/opt/provider/software_collection/X11 /etc/opt/provider/software_collection/X11/applnk /etc/opt/provider/software_collection/X11/fontpath.d ... /opt/provider/software_collection/root/usr/src /opt/provider/software_collection/root/usr/src/debug /opt/provider/software_collection/root/usr/src/kernels /opt/provider/software_collection/root/usr/tmp /var/opt/provider/software_collection /var/opt/provider/software_collection/cache /var/opt/provider/software_collection/db /var/opt/provider/software_collection/empty ...
3.1.2. Registering and Deregistering Software Collections
scl register
command:
$
scl register /opt/provider/software_collection
enable
scriptlet and the root/
directory to be considered a valid Software Collection file system hierarchy.
deregister
scriptet when running the scl
command:
$
scl deregister software_collection
3.1.2.1. Using (de)register Scriptlets in a Software Collection Metapackage
%file
section of the metapackage spec file.
%install %scl_install cat >> %{buildroot}%{_scl_scripts}/enable << EOF # Contents of the enable scriptlet goes here ... EOF cat >> %{buildroot}%{_scl_scripts}/register << EOF # Contents of the register scriptlet goes here ... EOF cat >> %{buildroot}%{_scl_scripts}/deregister << EOF # Contents of the deregister scriptlet goes here ... EOF ... %files runtime -f filelist %scl_files %{_scl_scripts}/register %{_scl_scripts}/deregister
/etc/opt/
or /var/opt/
.
3.2. Converting Software Collection Scriptlets into Environment Modules
enable
scriptlet into an environment module with a script /usr/share/Modules/bin/createmodule.sh
.
Procedure 3.1. Converting an enable scriptlet into an environment module
- Ensure that an environment-modules package is installed on your system:
#
yum install environment-modules
- Run the
/usr/share/Modules/bin/createmodule.sh
script to convert your Software Collection'senable
scriptlet into an environment module:/usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet
Replace /path/to/enable/scriptlet with the file path of theenable
scriptlet you want to convert. - Add the same command
/usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet
in the%pre
section of your Software Collection metapackage, below the code generating yourenable
scriptlet.In case you have theenable
scriptlet packaged as a file in one of your Software Collection packages, add the command/usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet
in the%post
section.
3.3. Providing syspaths Subpackages
scl enable
call, which changes environment variables, such as PATH
or LD_LIBRARY_PATH
, so that binaries installed in alternative locations can be found. Users also need to use alternative names for systemd services. Some scripts may also call binaries using full paths, for example /usr/bin/mysql
, and as a result, those scripts may not work with the Software Collection.
/usr/bin/
). This means that by choosing to install the syspaths subpackages, users deliberately alter the base system installation, making the syspaths subpackages typically suitable for users who do not require installing and running multiple versions of the same package at a time. This is especially the case when using databases.
3.3.1. Naming syspaths Subpackages
binary_1
included in the software_collection_1-package_1 package and a binary file binary_2
included in the software_collection_1-package_2 package, then create the following three syspaths subpackages in the software_collection_1 Software Collection:
software_collection_1-syspaths software_collection_1-package_1-syspaths software_collection_1-package_2-syspaths
3.3.2. Files Included in syspaths Subpackages
binary_1
included in the software_collection_1 and located in /opt/rh/software_collection_1/root/usr/bin/binary_1
:
#!/bin/bash source scl_source enable software_collection_1 exec "/opt/rh/software_collection_1/root/usr/bin/binary_1" "$@"
/usr/bin/binary_1
and make it executable, users can then simply run the binary_1
command without the need to prefix it with scl enable software_collection_1
. The wrapper installed in /usr/bin/
sets up the correct environment and executes the target binary located withing the /opt/provider/%{scl}
file system hierarchy.
3.3.3. Limitations of syspaths Wrappers
/opt/provider/%{scl}
file system hierarchy needs to be used, because gdb does not work with wrapper shell scripts.
3.3.4. Symbolic Links in syspaths Subpackages
/opt
, /etc/opt/
, or /var/opt/
directories, and thus can be provided by syspaths subpackages. For example, you can make the path to database files (normally located under /var/opt/provider/%{scl}
) easier to discover with a symbolic link located in /var/lib/
. However, for some symbolic links, it is better not to install them in /var/lib/
under their original name as they may conflict with the name of the conventional RPM package from the base system installation.
/var/lib/software_collection_1-original_name
or similar. For log files, a recommended name is /var/log/software_collection_1-original_name
or similar. Keep in mind that the name itself is not important, the design goal here is make those files easy to find under the /var/lib/
or /var/log/
directories.
/etc
directory.
3.3.5. Services Without a Prefix
scl enable
in the command when starting services, because services are by design started in a clean environment. But still, users are required to use the correct service name, usually prefixed with the Software Collection name (for example, rh-mariadb102-mariadb
).
mariadb
, mongod
, or postgresql
, if the appropriate syspaths subpackage is installed. To achieve this, create a symbolic link, without including the Software Collection name in the symbolic link name, that points to the conventional service file.
service_1
in the software_collection_1 Software Collection that is normally provided by the file /etc/rc.d/init.d/software_collection_1-service_1
can be accessed as service_1
by creating the following symbolic link:
/etc/rc.d/init.d/service_1 -> /etc/rc.d/init.d/software_collection_1-service_1
/usr/lib/systemd/system/service_1 -> /usr/lib/systemd/system/software_collection_1-service_1
3.4. Managing Services in Software Collections
service
or chkconfig
on Red Hat Enterprise Linux 6, or systemctl
on Red Hat Enterprise Linux 7.
%install
section of the spec file as follows to avoid possible name conflicts with the system versions of the services that are part of the Software Collection:
%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/rc.d/init.d/%{?scl_prefix}service_name
%install
section of the spec file as follows:
%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{_unitdir}/%{?scl_prefix}service_name.service
%{?scl_prefix}service_name
3.4.1. Configuring an Environment for Services
Procedure 3.2. Configuring an environment for services on Red Hat Enterprise Linux 6
- Create a configuration file in
/opt/provider/software_collection/service-environment
with the following content:[SCLNAME]_SCLS_ENABLED="software_collection"
Replace SCLNAME with a unique identifier for your Software Collection, for instance, your Software Collection's name written in capital letters.Replace software_collection with the name of your Software Collection as defined by the%scl_name
macro. - Add the following line at the beginning of the SysV init script:
source /opt/provider/software_collection/service-environment
- In the SysV init script, determine commands that run binaries located in the
/opt/provider/
file system hierarchy. Prefix these commands withscl enable $[SCLNAME]_SCLS_ENABLED
, similarly to when you run a command in the Software Collection environment.For example, replace the following line:/usr/bin/daemon_binary --argument-1 --argument-2
with:scl enable $[SCLNAME]_SCLS_ENABLED -- /usr/bin/daemon_binary --argument-1 --argument-2
- Some commands, like
su
orrunuser
, also clear environment variables. Thus, if these commands are used in the SysV init script, enable your Software Collection again after running these commands.For instance, replace the following line:su - user_name -c '/usr/bin/daemon_binary --argument-1 --argument-2'
with:su - user_name -c '\ source /opt/provider/software_collection/service-environment \ scl enable $SCLNAME_SCLS_ENABLED -- /usr/bin/daemon_binary --argument-1 --argument-2'
Procedure 3.3. Configuring an environment for services on Red Hat Enterprise Linux 7
- Create a configuration file in
/opt/provider/software_collection/service-environment
with the following content:[SCLNAME]_SCLS_ENABLED="software_collection"
Replace SCLNAME with a unique identifier for your Software Collection, for instance, your Software Collection's name written in capital letters.Replace software_collection with the name of your Software Collection as defined by the%scl_name
macro. - Add the following line in the systemd service file to load the configuration file:
EnvironmentFile=/opt/provider/software_collection/service-environment
- In the systemd service file, prefix all commands specified in
ExecStartPre
,ExecStart
, and similar directives withscl enable $[SCLNAME]_SCLS_ENABLED
, similarly to when you run a command in the Software Collection environment:ExecStartPre=/usr/bin/scl enable $[SCLNAME]_SCLS_ENABLED -- /opt/provider/software_collection/root/usr/bin/daemon_helper_binary --argument-1 --argument-2 ExecStart=/usr/bin/scl enable $[SCLNAME]_SCLS_ENABLED -- /opt/provider/software_collection/root/usr/bin/daemon_binary --argument-1 --argument-2
Warning
ExecStart*
commands with scl enable ...
as described above will prevent the service from transitioning to its target SELinux context indicated by the SELinux policy in effect. If the service is supposed to be confined using SELinux, the systemd service file needs to execute the binary directly. If the binary is linked against shared libraries which are part of the Software Collection, the DT_RUNPATH
attribute may help make those shared libraries accessible at runtime without the need for using the scl enable ...
wrapper. See Section 3.15.1, “SELinux Support in Red Hat Enterprise Linux 7” for more information.
3.5. Software Collection Library Support
LD_LIBRARY_PATH
environment variable in the enable
scriptlet as follows:
export LD_LIBRARY_PATH="%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}}"
Note
DT_RUNPATH
attribute instead of the LD_LIBRARY_PATH
environment variable to make the private shared library accessible in the Software Collection environment.
3.5.1. Using a Library Outside of the Software Collection
/etc/ld.so.conf.d/
for this purpose.
Warning
/etc/ld.so.conf.d/
for libraries already available on the system. Using /etc/ld.so.conf.d/
is only recommended for a library that is not available on the system, as otherwise the version of the library in the Software Collection might get preference over the system version of the library. That could lead to undesired behavior of the system versions of the applications, including unexpected termination and data loss.
Procedure 3.4. Using /etc/ld.so.conf.d/ for libraries in the Software Collection
- Create a file named
%{?scl_prefix}libs.conf
and adjust the spec file configuration accordingly:SOURCE2: %{?scl_prefix}libs.conf
- In the
%{?scl_prefix}libs.conf
file, include a list of directories where the versions of the libraries associated with the Software Collection are located. For example:/opt/provider/software_collection_1/root/usr/lib64/
In the example above, the/usr/lib64/
directory that is part of the Software Collection software_collection_1 is included in the list. - Edit the
%install
section of the spec file, so the%{?scl_prefix}libs.conf
file is installed as follows:%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/ld.so.conf.d/
3.5.2. Prefixing the Library Major soname with the Software Collection Name
scl enable
command when building an application against a library included in the Software Collection. Failing to do so may result in the application being executed in an incorrect environment, linked against the incorrect system version of the library.
Warning
LD_LIBRARY_PATH
environment variable has not been set properly, change the major soname of the library included in the Software Collection. The recommended way to change the major soname is to prefix the major soname version number with the Software Collection name.
mysql55-
prefix:
$
rpm -ql mysql55-mysql-libs | grep 'lib.*so'
/opt/provider/mysql55/root/usr/lib64/mysql/libmysqlclient.so.mysql55-18 /opt/provider/mysql55/root/usr/lib64/mysql/libmysqlclient.so.mysql55-18.0.0
$ rpm -ql mysql-libs | grep 'lib.*so'
/usr/lib64/mysql/libmysqlclient.so.18
/usr/lib64/mysql/libmysqlclient.so.18.0.0
rpmbuild
utility generates an automatic Provides
tag for packages that include a versioned shared library. If you do not prefix the soname as described above, then an example of the Provides
in case of the mysql package is libmysqlclient.so.18()(64bit)
. With this Provides
, RPM can choose the incorrect RPM package, resulting in the application missing the requirement.
Provides
in case of mysql is libmysqlclient.so.mysql55-18()(64bit)
. With this Provides
, RPM chooses the correct RPM dependencies and the application's requirements are satisfied.
3.5.3. Software Collection Library Support in Red Hat Enterprise Linux 7
%__provides_exclude_from
macro to prevent scanning certain files for automatically generated RPM symbols.
.so
files in the %{_libdir}
directory, add the following lines before the BuildRequires
or Requires
tags in your Software Collection spec file:
%if %{?scl:1}%{!?scl:0} # Do not scan .so files in %{_libdir} %global __provides_exclude_from ^%{_libdir}/.*.so.*$ %endif
Provides
and Requires
, see Section 2.10.5, “Software Collection Automatic Provides and Requires and Filtering Support” for more information.
3.6. Software Collection .pc Files Support
PKG_CONFIG_PATH
environment variable. Depending on what is defined in your .pc files, update the PKG_CONFIG_PATH
environment variable for the %{_libdir}
macro (which expands to the library directory, typically /usr/lib/
or /usr/lib64/
), or for the %{_datadir}
macro (which expands to the share directory, typically /usr/share/
).
PKG_CONFIG_PATH
environment variable by adjusting the %install
section of the Software Collection spec file as follows:
%install cat >> %{buildroot}%{_scl_scripts}/enable << EOF export PKG_CONFIG_PATH="%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}}" EOF
PKG_CONFIG_PATH
environment variable by adjusting the %install
section of the Software Collection spec file as follows:
%install cat >> %{buildroot}%{_scl_scripts}/enable << EOF export PKG_CONFIG_PATH="%{_datadir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}}" EOF
enable
scriptlet so that it ensures that the .pc files in the Software Collection are preferred over the .pc files available on the system if the Software Collection is enabled.
/usr/bin/
directory. In this case, ensure that the .pc files are visible to the system even if the Software Collection is disabled.
PKG_CONFIG_PATH
environment variable with the paths to the .pc files associated with the Software Collection. Depending on what is defined in your .pc files, update the PKG_CONFIG_PATH
environment variable for the %{_libdir}
macro (which expands to the library directory), or for the %{_datadir}
macro (which expands to the share directory).
Procedure 3.5. Updating the PKG_CONFIG_PATH environment variable for %{_libdir}
- To update the
PKG_CONFIG_PATH
environment variable for the%{_libdir}
macro, create a custom script/etc/profile.d/name.sh
. The script is preloaded when a shell is started on the system.For example, create the following file:%{?scl_prefix}pc-libdir.sh
- Use the
pc-libdir.sh
short script that modifies thePKG_CONFIG_PATH
variable to refer to your .pc files:export PKG_CONFIG_PATH="%{_libdir}/pkgconfig:/opt/provider/software_collection/path/to/your/pc_files"
- Add the file to your Software Collection package's spec file:
SOURCE2: %{?scl_prefix}pc-libdir.sh
- Install this file into the system
/etc/profile.d/
directory by adjusting the%install
section of the Software Collection package's spec file:%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/profile.d/
Procedure 3.6. Updating the PKG_CONFIG_PATH environment variable for %{_datadir}
- To update the
PKG_CONFIG_PATH
environment variable for the%{_datadir}
macro, create a custom script/etc/profile.d/name.sh
. The script is preloaded when a shell is started on the system.For example, create the following file:%{?scl_prefix}pc-datadir.sh
- Use the
pc-datadir.sh
short script that modifies thePKG_CONFIG_PATH
variable to refer to your .pc files:export PKG_CONFIG_PATH="%{_datadir}/pkgconfig:/opt/provider/software_collection/path/to/your/pc_files"
- Add the file to your Software Collection package's spec file:
SOURCE2: %{?scl_prefix}pc-datadir.sh
- Install this file into the system
/etc/profile.d/
directory by adjusting the%install
section of the Software Collection package's spec file:%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/profile.d/
3.7. Software Collection MANPATH Support
man
command on the system to display man pages from the enabled Software Collection, update the MANPATH
environment variable with the paths to the man pages that are associated with the Software Collection.
MANPATH
environment variable, add the following to the %install
section of the Software Collection spec file:
%install cat >> %{buildroot}%{_scl_scripts}/enable << EOF export MANPATH="%{_mandir}:\${MANPATH:-}" EOF
enable
scriptlet to update the MANPATH
environment variable. The man pages associated with the Software Collection are then not visible as long as the Software Collection is not enabled.
/usr/bin/
directory. In this case, ensure that the man pages are visible to the system even if the Software Collection is disabled.
man
command on the system to display man pages from the disabled Software Collection, update the MANPATH
environment variable with the paths to the man pages associated with the Software Collection.
Procedure 3.7. Updating the MANPATH environment variable for the disabled Software Collection
- To update the
MANPATH
environment variable, create a custom script/etc/profile.d/name.sh
. The script is preloaded when a shell is started on the system.For example, create the following file:%{?scl_prefix}manpage.sh
- Use the
manpage.sh
short script that modifies theMANPATH
variable to refer to your man path directory:export MANPATH="/opt/provider/software_collection/path/to/your/man_pages:${MANPATH}"
- Add the file to your Software Collection package's spec file:
SOURCE2: %{?scl_prefix}manpage.sh
- Install this file into the system
/etc/profile.d/
directory by adjusting the%install
section of the Software Collection package's spec file:%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/profile.d/
3.8. Software Collection cronjob Support
Procedure 3.8. Running periodic tasks with cronjobs
- To use cronjobs for running periodic tasks, place a
crontab
file for your Software Collection in the/etc/cron.d/
directory with the Software Collection's name.For example, create the following file:%{?scl_prefix}crontab
- Ensure that the contents of the
crontab
file follow the standardcrontab
file format, as in the following example:0 1 * * Sun root scl enable software_collection '
/opt/provider/software_collection/root/usr/bin/cron_job_name
'where software_collection is the name of your Software Collection, and/opt/provider/software_collection/root/usr/bin/cron_job_name
is the command you want to periodically run. - Add the file to your spec file of the Software Collection package:
SOURCE2: %{?scl_prefix}crontab
- Install the file into the system directory
/etc/cron.d/
by adjusting the%install
section of the Software Collection package's spec file:%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/cron.d/
3.9. Software Collection Log File Support
/opt/provider/%{scl}/root/var/log/
directory.
nfsmountable
macro that redefines the _localstatedir
macro. This results in log files being created underneath the /var/opt/provider/%{scl}/log/
directory, outside of the /opt/provider/%{scl}
file system hierarchy.
/var/log/mydaemon/mydaemond.log
in the base system installation. When mydaemon is packaged as a software_collection Software Collection and the nfsmountable
macro is defined, the path to the log file in software_collection is as follows:
/var/opt/provider/software_collection/log/mydaemon/mydaemond.log
nfsmountable
macro, see Section 3.1, “Using Software Collections over NFS”.
3.10. Software Collection logrotate Support
Procedure 3.9. Managing log files with logrotate
- To manage your log files with logrotate, place a custom logrotate file for your Software Collection in the system directory for the logrotate jobs
/etc/logrotate.d/
.For example, create the following file:%{?scl_prefix}logrotate
- Ensure that the contents of the
logrotate
file follow the standardlogrotate
file format as follows:/opt/provider/software_collection/var/log/your_application_name.log { missingok notifempty size 30k yearly create 0600 root root }
- Add the file to your spec file of the Software Collection package:
SOURCE2: %{?scl_prefix}logrotate
- Install the file into the system directory
/etc/logrotate.d/
by adjusting the%install
section of the Software Collection package's spec file:%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/logrotate.d/
3.11. Software Collection /var/run/ Files Support
/var/run/package_name/
directory. When packaging PID files into your Software Collection, you are advised to use the nfsmountable
macro and store the PID files in the following directory:
/var/run/software_collection-package_name/
/var/run/
features, for example the tmpfs
file system for PID files.
nfsmountable
macro, see Section 3.1, “Using Software Collections over NFS”.
3.12. Software Collection Lock File Support
/opt/provider/%{scl}/root/var/lock/
directory.
nfsmountable
macro that redefines the _localstatedir
macro. This results in lock files being created underneath the /var/opt/provider/%{scl}/lock/
directory, outside of the /opt/provider/%{scl}
file system hierarchy.
/var/opt/provider/%{scl}/lock/
directory, then those applications and services can run concurrently with the system versions (when the resources of your Software Collection's applications and services will not conflict with the system versions' resources).
mylockfile.lock
is normally created in the /var/lock/
directory in the base system installation. If the lock file is a part of a software_collection Software Collection and the nfsmountable
macro is defined, the path to the lock file in software_collection is as follows:
/var/opt/provider/software_collection/lock/mylockfile.lock
nfsmountable
macro, see Section 3.1, “Using Software Collections over NFS”.
Preventing Programs from Running Concurrently
/var/lock/
. In this way, your applications or services' lock file will not be overwritten. The lock file will not be renamed and the name stays the same as the system version.
3.12.1. Software Collection SysV init Lock File Support
/var/lock/subsys/
directory with the same name as the init script. As discussed in Section 3.4, “Managing Services in Software Collections”, service names include a Software Collection prefix. Use the same naming convention for files underneath /var/lock/subsys/
to ensure that the lock file names do not conflict with the base system installation.
3.13. Software Collection Configuration Files Support
/opt/provider/%{scl}
file system hierarchy.
nfsmountable
macro that redefines the _sysconfdir
macro. This results in configuration files being created underneath the /etc/opt/provider/%{scl}/
directory, outside of the /opt/provider/%{scl}
file system hierarchy.
/etc
directory in the base system installation. If the configuration file is a part of a software_collection Software Collection and the nfsmountable
macro is defined, the path to the configuration file in software_collection is as follows:
/etc/opt/provider/software_collection/example.conf
nfsmountable
macro, see Section 3.1, “Using Software Collections over NFS”.
3.14. Software Collection Kernel Module Support
- the name of your kernel module package includes the kernel version,
- the tag
Requires
, which can be found in your kernel module spec file, includes the kernel version and revision (in the formatkernel-version-revision
).
3.15. Software Collection SELinux Support
semanage fcontext
and restorecon
commands to set up the SELinux labels.
/opt/provider/software_collection_1/root/usr/
directory in your Software Collection package imitates the /usr/
directory of your conventional package, set up the SELinux labels as follows:
semanage fcontext -a -e /usr /opt/provider/software_collection_1/root/usr
restorecon -R -v /opt/provider/software_collection_1/root/usr
/opt/provider/software_collection_1/root/usr/
directory are labeled by SELinux as if they were located in the /usr/
directory.
3.15.1. SELinux Support in Red Hat Enterprise Linux 7
%post
section in the Software Collection metapackage to set up the SELinux labels:
semanage fcontext -a -e /usr /opt/provider/software_collection_1/root/usr
restorecon -R -v /opt/provider/software_collection_1/root/usr
selinuxenabled && load_policy || :
restorecon
command in all packages in the Software Collection.
semanage fcontext
command is provided by the policycoreutils-python package, therefore it is important that you include policycoreutils-python
in Requires
for the Software Collection metapackage.
Note
scl enable ...
wrapper in a systemd service file will cause the service to be run as an unconfined process using the unconfined_service_t
context. As this context has no transition rules by design, the service will not be able to transition into the target SELinux context indicated by the SELinux policy, which means scl enable ...
cannot be used on Red Hat Enterprise Linux 7 if the service being started is supposed to be confined using SELinux.
3.16. Differences Between Red Hat Enterprise Linux 6 and 7
3.16.1. The %license Macro
%license
macro allows you to specify the license file to be installed by your package. The macro is only supported by the RPM Package Manager in Red Hat Enterprise Linux 7. When building your Software Collection package on both Red Hat Enterprise Linux 6 and 7, declare the %license
macro for Red Hat Enterprise Linux 6 as follows:
%{!?_licensedir:%global license %%doc}
3.16.2. Missing runtime Subpackage Dependencies
Requires
on the Software Collection runtime subpackage. This does not work on Red Hat Enterprise Linux 6. When building your Software Collection for that system, you need to explicitly specify the dependency on the runtime subpackage in each Software Collection package:
Requires: %{?scl_prefix}runtime
3.16.3. The scl-package() Provides
Provide: scl-package()
tags. The purpose of these is to internally identify the built package as belonging to a specific Software Collection. The tags are detailed in the following table.
Software Collection package
|
Provide
|
---|---|
| scl-package(software_collection_1)
|
${software_collection_1}-build
| scl-package(software_collection_1)
|
${software_collection_1}-runtime
| scl-package(software_collection_1)
|
Provide: scl-package()
tag, as detailed in the following table. This is an expected behavior and the differences are handled internally by the scl tool.
Software Collection package
|
Provide
|
---|---|
${software_collection_1}
| scl-package(software_collection_1)
|
Chapter 4. Extending Red Hat Software Collections
4.1. Providing an scldevel Subpackage
4.1.1. Creating an scldevel Subpackage
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.2. Using an scldevel Subpackage in a Dependent Software Collection
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
- 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
SpecifyingRequires: %{scl_prefix_ruby}scldevel
ensures that macros are available in all packages of the Software Collection.Note that adding thisRequires
only makes sense in specific use cases, such as where packages in a dependent Software Collection use macros provided by the scldevel subpackage.
4.2. Extending the python27 and rh-python35 Software Collections
%scl_package_override()
, which allows for easier packaging of your own dependent Software Collection.
4.2.1. The vt191 Software Collection
vt191
and contains the versiontools Python package version 1.9.1.
- The vt191 Software Collection metapackage has the following build dependency set:
BuildRequires: %{scl_prefix_python}scldevel
This expands to, for example, python27-scldevel.The python27-scldevel subpackage ships two important macros,%scl_python
and%scl_prefix_python
. Note that these macros are defined at the top of the metapackage spec file. Although the definitions are not required, they provide a visual hint that the vt191 Software Collection has been designed to be built on top of the python27 Software Collection. They also serve as a fallback value. - To have a
site-packages
directory set up properly, use the value of the%python27python_sitelib
macro and replacepython27
withvt191
. Note that if you are building the Software Collection with a different provider (for example,/opt/myorganization/
instead of/opt/rh/
), you will need to change these, too.Important
Because the/opt/rh/
provider is used to install Software Collections provided by Red Hat, it is strongly recommended to use a different provider to avoid possible conflicts. See Section 2.3, “The Software Collection Root Directory” for more information. - The vt191-build subpackage has the following dependency set:
Requires: %{scl_prefix_python}scldevel
This expands to, for example, python27-scldevel. The purpose of this dependency is to ensure that the macros are always present when building packages for the vt191 Software Collection. - The
enable
scriptlet for the vt191 Software Collection uses the following line:. scl_source enable %{scl_python}
Note the dot at the beginning of the line. This line makes the Python Software Collection start implicitly when the vt191 Software Collection is started so that the user can only typescl enable vt191 command
instead ofscl enable python27 vt191 command
to run command in the Software Collection environment. - The macro file
macros.vt191-config
calls the%scl_package_override
function to properly override%__os_install_post
, Python dependency generators, and certain Python-specific macros used in other packages' spec files.
# define name of the scl %global scl vt191 %scl_package %scl # Defaults for the values for the python27/rh-python35 Software Collection. These # will be used when python27-scldevel (or rh-python35-scldevel) is not in the # build root %{!?scl_python:%global scl_python python27} %{!?scl_no_vendor:%global scl_no_vendor python27} %{!?scl_prefix_python:%global scl_prefix_python %{scl_python}-} # Only for this build, you need to override default __os_install_post, # because the default one would find /opt/.../lib/python2.7/ and try # to bytecompile with the system /usr/bin/python2.7 %global __os_install_post %{%{scl_no_vendor}_os_install_post} # Similarly, override __python_requires for automatic dependency generator %global __python_requires %{%{scl_no_vendor}_python_requires} # The directory for site packages for this Software Collection %global vt191_sitelib %(echo %{python27python_sitelib} | sed 's|%{scl_python}|%{scl}|') Summary: Package that installs %scl Name: %scl_name Version: 1 Release: 1%{?dist} License: GPLv2+ BuildRequires: scl-utils-build # Always make sure that there is the python27-sclbuild (or rh-python35-sclbuild) # package in the build root BuildRequires: %{scl_prefix_python}scldevel # Require python27-python-devel, you will need macros from that package BuildRequires: %{scl_prefix_python}python-devel Requires: %{scl_prefix}python-versiontools %description This is the main package for %scl Software Collection. %package runtime Summary: Package that handles %scl Software Collection. Requires: scl-utils Requires: %{scl_prefix_python}runtime %description runtime Package shipping essential scripts to work with %scl Software Collection. %package build Summary: Package shipping basic build configuration Requires: scl-utils-build # Require python27-scldevel (or rh-python35-scldevel) so that there is always access # to the %%scl_python and %%scl_prefix_python macros in builds for this Software # Collection Requires: %{scl_prefix_python}scldevel %description build Package shipping essential configuration macros to build %scl Software Collection. %prep %setup -c -T %install %scl_install # Create the enable scriptlet that: # - Adds an additional load path for the Python interpreter. # - Runs scl_source so that you can run: # scl enable vt191 "bash" # instead of: # scl enable python27 vt191 "bash" cat >> %{buildroot}%{_scl_scripts}/enable << EOF . scl_source enable %{scl_python} export PYTHONPATH="%{vt191_sitelib}\${PYTHONPATH:+:\${PYTHONPATH}}" EOF mkdir -p %{buildroot}%{vt191_sitelib} # - Enable Software Collection-specific bytecompilation macros from # the python27-python-devel package. # - Also override the %%python_sitelib macro to point to the vt191 Software # Collection. # - If you have architecture-dependent packages, you will also need to override # the %%python_sitearch macro. cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl}-config << EOF %%scl_package_override() %%{expand:%{?python27_os_install_post:%%global __os_install_post %%python27_os_install_post} %%global __python_requires %%python27_python_requires %%global __python_provides %%python27_python_provides %%global __python %python27__python %%global python_sitelib %vt191_sitelib %%global python2_sitelib %vt191_sitelib } EOF %files %files runtime -f filelist %scl_files %vt191_sitelib %files build %{_root_sysconfdir}/rpm/macros.%{scl}-config %changelog * Wed Jan 22 2014 John Doe <jdoe@example.com> - 1-1 - Initial package.
4.2.2. The python-versiontools Package
- The
BuildRequires
tags are prefixed with%{?scl_prefix_python}
instead of%{scl_prefix}
. - The
%install
section explictly specifies--install-purelib
.
%{?scl:%scl_package python-versiontools} %{!?scl:%global pkg_name %{name}} %global pypi_name versiontools Name: %{?scl_prefix}python-versiontools Version: 1.9.1 Release: 1%{?dist} Summary: Smart replacement for plain tuple used in __version__ License: LGPLv3 URL: https://launchpad.net/versiontools Source0: http://pypi.python.org/packages/source/v/versiontools/versiontools-1.9.1.tar.gz BuildArch: noarch BuildRequires: %{?scl_prefix_python}python-devel BuildRequires: %{?scl_prefix_python}python-setuptools %{?scl:BuildRequires: %{scl}-build %{scl}-runtime} %{?scl:Requires: %{scl}-runtime} %description Smart replacement for plain tuple used in __version__ %prep %setup -q -n %{pypi_name}-%{version} %build %{?scl:scl enable %{scl} "} %{__python} setup.py build %{?scl:"} %install # Explicitly specify --install-purelib %{python_sitelib}, which is now overriden # to point to vt191, otherwise Python will try to install into the python27 # Software Collection site-packages directory %{?scl:scl enable %{scl} "} %{__python} setup.py install -O1 --skip-build --root %{buildroot} --install-purelib %{python_sitelib} %{?scl:"} %files %{python_sitelib}/%{pypi_name}* %changelog * Wed Jan 22 2014 John Doe <jdoe@example.com> - 1.9.1-1 - Built for vt191 SCL.
4.2.3. Building the vt191 Software Collection
- Install the python27-scldevel and python27-python-devel subpackages that are part of the python27 Software Collection.
- Build
vt191.spec
and install the vt191-runtime and vt191-build packages. - Install the python27-python-setuptools package, which is a build requirement for versiontools.
- Build
python-versiontools.spec
.
4.2.4. Testing the vt191 Software Collection
- Install the vt191-python-versiontools package.
- Run the following command:
$
scl enable vt191 "python -c 'import versiontools; print(versiontools.__file__)'"
- Verify that the output contains the following line:
/opt/rh/vt191/root/usr/lib/python2.7/site-packages/versiontools/__init__.pyc
Note that the providerrh
in the path may vary depending on your redefinition of the%_scl_prefix
macro. See Section 2.3, “The Software Collection Root Directory” for more information.
4.3. Extending the rh-ruby23 Software Collection
4.3.1. The rh-ror42 Software Collection
- The rh-ror42 Software Collection spec file has the following build dependencies set:
BuildRequires: %{scl_prefix_ruby}scldevel BuildRequires: %{scl_prefix_ruby}rubygems-devel
This expands to, for example, rh-ruby23-scldevel and rh-ruby23-rubygems-devel.The rh-ruby23-scldevel subpackage contains two important macros,%scl_ruby
and%scl_prefix_ruby
. The rh-ruby23-scldevel subpackage should be available in the build root. In case there are multiple Ruby Software Collections available, rh-ruby23-scldevel determines which of the available Software Collections should be used.Note that the%scl_ruby
and%scl_prefix_ruby
macros are also defined at the top of the spec file. Although the definitions are not required, they provide a visual hint that the rh-ror42 Software Collection has been designed to be built on top of the rh-ruby23 Software Collection. They also serve as a fallback value. - The rh-ror42-runtime subpackage must depend on the runtime subpackage of the Software Collection it depends on. This dependency is specified as follows:
%package runtime Requires: %{scl_prefix_ruby}runtime
When the package is built against the rh-ruby23 Software Collection, this expands to rh-ruby23-runtime. - The rh-ror42-build subpackage must depend on the scldevel subpackage of the Software Collection it depends on. This is to ensure that all other packages of this Software Collection will have the same macros defined, thus it is built against the same Ruby version.
%package build Requires: %{scl_prefix_ruby}scldevel
In the case of the rh-ruby23 Software Collection, this expands to rh-ruby23-scldevel. - The
enable
scriptlet for the rh-ror42 Software Collection contains the following line:. scl_source enable %{scl_ruby}
Note the dot at the beginning of the line. This line makes the Ruby Software Collection start implicitly when the rh-ror42 Software Collection is started so that the user can only typescl enable rh-ror42 command
instead ofscl enable rh-ruby23 rh-ror42 command
to run command in the Software Collection environment. - The rh-ror42-scldevel subpackage is provided so that it is available in case you need it to build a Software Collection which extends the rh-ror42 Software Collection. The package provides the
%{scl_ror}
and%{scl_prefix_ror}
macros, which can be used to extend the rh-ror42 Software Collection. - Because the rh-ror42 Software Collection's gems are installed in a separate root directory structure, you need to ensure that the correct ownership for the rubygems directories is set. This is done by using a snippet to generate a file list rubygems_filesystem.list.You are advised to set the runtime package to own all directories which would, if located in the root file system, be owned by another package. One example of such directories in the case of the rh-ror42 Software Collection is the Rubygem directory structure.
%global scl_name_prefix rh- %global scl_name_base ror %global scl_name_version 41 %global scl %{scl_name_prefix}%{scl_name_base}%{scl_name_version} # Fallback to rh-ruby23. rh-ruby23-scldevel is unlikely to be available in # the build root. %{!?scl_ruby:%global scl_ruby rh-ruby23} %{!?scl_prefix_ruby:%global scl_prefix_ruby %{scl_ruby}-} # Do not produce empty debuginfo package. %global debug_package %{nil} # Support SCL over NFS. %global nfsmountable 1 %{!?install_scl: %global install_scl 1} %scl_package %scl Summary: Package that installs %scl Name: %scl_name Version: 2.0 Release: 5%{?dist} License: GPLv2+ %if 0%{?install_scl} Requires: %{scl_prefix}rubygem-therubyracer Requires: %{scl_prefix}rubygem-sqlite3 Requires: %{scl_prefix}rubygem-rails Requires: %{scl_prefix}rubygem-sass-rails Requires: %{scl_prefix}rubygem-coffee-rails Requires: %{scl_prefix}rubygem-jquery-rails Requires: %{scl_prefix}rubygem-sdoc Requires: %{scl_prefix}rubygem-turbolinks Requires: %{scl_prefix}rubygem-bcrypt Requires: %{scl_prefix}rubygem-uglifier Requires: %{scl_prefix}rubygem-jbuilder Requires: %{scl_prefix}rubygem-spring %endif BuildRequires: help2man BuildRequires: scl-utils-build BuildRequires: %{scl_prefix_ruby}scldevel BuildRequires: %{scl_prefix_ruby}rubygems-devel %description This is the main package for %scl Software Collection. %package runtime Summary: Package that handles %scl Software Collection. Requires: scl-utils # The enable scriptlet depends on the ruby executable. Requires: %{scl_prefix_ruby}ruby %description runtime Package shipping essential scripts to work with %scl Software Collection. %package build Summary: Package shipping basic build configuration Requires: scl-utils-build Requires: %{scl_runtime} Requires: %{scl_prefix_ruby}scldevel %description build Package shipping essential configuration macros to build %scl Software Collection. %package scldevel Summary: Package shipping development files for %scl Provides: scldevel(%{scl_name_base}) %description scldevel Package shipping development files, especially usefull for development of packages depending on %scl Software Collection. %prep %setup -c -T %install %scl_install cat >> %{buildroot}%{_scl_scripts}/enable << EOF export PATH="%{_bindir}:%{_sbindir}\${PATH:+:\${PATH}}" export LD_LIBRARY_PATH="%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}}" export MANPATH="%{_mandir}:\${MANPATH:-}" export PKG_CONFIG_PATH="%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}}" export GEM_PATH="\${GEM_PATH:=%{gem_dir}:\`scl enable %{scl_ruby} -- ruby -e "print Gem.path.join(':')"\`}" . scl_source enable %{scl_ruby} EOF cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF %%scl_%{scl_name_base} %{scl} %%scl_prefix_%{scl_name_base} %{scl_prefix} EOF scl enable %{scl_ruby} - << \EOF set -e # Fake rh-ror42 Software Collection environment. GEM_PATH=%{gem_dir}:`ruby -e "print Gem.path.join(':')"` \ X_SCLS=%{scl} \ ruby -rfileutils > rubygems_filesystem.list << \EOR # Create the RubyGems file system. Gem.ensure_gem_subdirectories '%{buildroot}%{gem_dir}' FileUtils.mkdir_p File.join '%{buildroot}', Gem.default_ext_dir_for('%{gem_dir}') # Output the relevant directories. Gem.default_dirs['%{scl}_system'.to_sym].each { |k, p| puts p } EOR EOF %files %files runtime -f rubygems_filesystem.list %scl_files %files build %{_root_sysconfdir}/rpm/macros.%{scl}-config %files scldevel %{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel %changelog * Thu Jan 16 2015 John Doe <jdoe@example.com> - 1-1 - Initial package.
4.3.2. The rh-ror42-rubygem-bcrypt Package
- The
BuildRequires
tags are prefixed with%{?scl_prefix_ruby}
instead of%{scl_prefix}
.
%{?scl:%scl_package rubygem-%{gem_name}} %{!?scl:%global pkg_name %{name}} %global gem_name bcrypt Summary: Wrapper around bcrypt() password hashing algorithm Name: %{?scl_prefix}rubygem-%{gem_name} Version: 3.1.9 Release: 2%{?dist} Group: Development/Languages # ext/* - Public Domain # spec/TestBCrypt.java - ISC License: MIT and Public Domain and ISC URL: https://github.com/codahale/bcrypt-ruby Source0: http://rubygems.org/downloads/%{gem_name}-%{version}.gem Requires: %{?scl_prefix_ruby}ruby(release) Requires: %{?scl_prefix_ruby}ruby(rubygems) BuildRequires: %{?scl_prefix_ruby}rubygems-devel BuildRequires: %{?scl_prefix_ruby}ruby-devel BuildRequires: %{?scl_prefix}rubygem(rspec) Provides: %{?scl_prefix}rubygem(bcrypt) = %{version} %description bcrypt() is a sophisticated and secure hash algorithm designed by The OpenBSD project for hashing passwords. bcrypt provides a simple, humane wrapper for safely handling passwords. %package doc Summary: Documentation for %{pkg_name} Group: Documentation Requires: %{?scl_prefix}%{pkg_name} = %{version}-%{release} %description doc Documentation for %{pkg_name}. %prep %setup -n %{pkg_name}-%{version} -q -c -T %{?scl:scl enable %{scl} - << \EOF} %gem_install -n %{SOURCE0} %{?scl:EOF} %build %install mkdir -p %{buildroot}%{gem_dir} cp -pa .%{gem_dir}/* \ %{buildroot}%{gem_dir}/ mkdir -p %{buildroot}%{gem_extdir_mri} cp -pa .%{gem_extdir_mri}/* %{buildroot}%{gem_extdir_mri}/ # Prevent a symlink with an invalid target in -debuginfo (BZ#878863). rm -rf %{buildroot}%{gem_instdir}/ext/ %check %{?scl:scl enable %{scl} - << \EOF} pushd .%{gem_instdir} # 2 failutes due to old RSpec # https://github.com/rspec/rspec-expectations/pull/284 rspec -I$(dirs +1)%{gem_extdir_mri} spec |grep '34 examples, 2 failures' || exit 1 popd %{?scl:EOF} %files %dir %{gem_instdir} %exclude %{gem_instdir}/.* %{gem_libdir} %{gem_extdir_mri} %exclude %{gem_cache} %{gem_spec} %doc %{gem_instdir}/COPYING %files doc %doc %{gem_docdir} %doc %{gem_instdir}/README.md %doc %{gem_instdir}/CHANGELOG %{gem_instdir}/Rakefile %{gem_instdir}/Gemfile* %{gem_instdir}/%{gem_name}.gemspec %{gem_instdir}/spec %changelog * Fri Mar 21 2015 John Doe <jdoe@example.com> - 3.1.2-4 - Initial package.
4.3.3. Building the rh-ror42 Software Collection
- Install the rh-ruby23-scldevel subpackage which is a part of the rh-ruby23 Software Collection.
- Build
rh-ror42.spec
and install the ror42-runtime and ror42-build packages. - Build
rubygem-bcrypt.spec
.
4.3.4. Testing the rh-ror42 Software Collection
- Install the rh-ror42-rubygem-bcrypt package.
- Run the following command:
$
scl enable rh-ror42 -- ruby -r bcrypt -e "puts BCrypt::Password.create('my password')"
- Verify that the output contains the following line:
$2a$10$s./ReniLY.wXPHVBQ9npoeyZf5KzywfpvI5lhjG6Ams3u0hKqwVbW
4.4. Extending the rh-perl524 Software Collection
Important
- do not provide any Perl modules, and
- only depend on Perl modules provided by the rh-perl524 Software Collection.
4.4.1. The h2m144 Software Collection
- The h2m144 Software Collection metapackage has the following build dependency set:
BuildRequires: %{scl_prefix_perl}scldevel
This expands to rh-perl524-scldevel.The rh-perl524-scldevel subpackage contains two important macros,%scl_perl
and%scl_prefix_perl
, and also provides Perl dependency generators. Note that the macros are defined at the top of the metapackage spec file. Although the definitions are not required, they provide a visual hint that the h2m144 Software Collection has been designed to be built on top of the rh-perl524 Software Collection. They also serve as a fallback value. - The h2m144-build subpackage has the following dependency set:
Requires: %{scl_prefix_perl}scldevel
This expands to rh-perl524-scldevel. The purpose of this dependency is to ensure that the macros and dependency generators are always present when building packages for the h2m144 Software Collection. - The
enable
scriptlet for the h2m144 Software Collection contains the following line:. scl_source enable %{scl_perl}
Note the dot at the beginning of the line. This line makes the Perl Software Collection start implicitly when the h2m144 Software Collection is started so that the user can only typescl enable h2m144 command
instead ofscl enable rh-perl524 h2m144 command
to run command in the Software Collection environment. - The macro file
macros.h2m144-config
calls the Perl dependency generators, and certain Perl-specific macros used in other packages' spec files.
%global scl h2m144 %scl_package %scl # Default values for the rh-perl524 Software Collection. These # will be used when rh-perl524-scldevel is not in the build root. %{!?scl_perl:%global scl_perl rh-perl524} %{!?scl_prefix_perl:%global scl_prefix_perl %{scl_perl}-} # Only for this build, override __perl_requires for the automatic dependency # generator. %global __perl_requires /usr/lib/rpm/perl.req.stack Summary: Package that installs %scl Name: %scl_name Version: 1 Release: 1%{?dist} License: GPLv2+ BuildRequires: scl-utils-build # Always make sure that there is the rh-perl524-scldevel # package in the build root. BuildRequires: %{scl_prefix_perl}scldevel # Require rh-perl524-perl-macros; you will need macros from that package. BuildRequires: %{scl_prefix_perl}perl-macros Requires: %{scl_prefix}help2man %description This is the main package for %scl Software Collection. %package runtime Summary: Package that handles %scl Software Collection. Requires: scl-utils Requires: %{scl_prefix_perl}runtime %description runtime Package shipping essential scripts to work with %scl Software Collection. %package build Summary: Package shipping basic build configuration Requires: scl-utils-build # Require rh-perl524-scldevel so that there is always access to the %%scl_perl # and %%scl_prefix_perl macros in builds for this Software Collection. Requires: %{scl_prefix_perl}scldevel %description build Package shipping essential configuration macros to build %scl Software Collection. %prep %setup -c -T %build %install %scl_install # Create the enable scriptlet that: # - Adds an additional load path for the Perl interpreter. # - Runs scl_source so that you can run: # scl enable h2m144 'bash' # instead of: # scl enable rh-perl524 h2m144 'bash' cat >> %{buildroot}%{_scl_scripts}/enable << EOF . scl_source enable %{scl_perl} export PATH="%{_bindir}:%{_sbindir}\${PATH:+:\${PATH}}" export MANPATH="%{_mandir}:\${MANPATH:-}" EOF cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl}-config << EOF %%scl_package_override() %%{expand:%%global __perl_requires /usr/lib/rpm/perl.req.stack %%global __perl_provides /usr/lib/rpm/perl.prov.stack %%global __perl %{_scl_prefix}/%{scl_perl}/root/usr/bin/perl } EOF %files %files runtime -f filelist %scl_files %files build %{_root_sysconfdir}/rpm/macros.%{scl}-config %changelog * Tue Apr 22 2014 John Doe <jdoe@example.com> - 1-1 - Initial package.
4.4.2. The help2man Package
- The
BuildRequires
tags are prefixed with%{?scl_prefix_perl}
instead of%{scl_prefix}
.
%{?scl:%scl_package help2man} %{!?scl:%global pkg_name %{name}} # Supported build option: # # --with nls ... build this package with --enable-nls %bcond_with nls Name: %{?scl_prefix}help2man Summary: Create simple man pages from --help output Version: 1.44.1 Release: 1%{?dist} Group: Development/Tools License: GPLv3+ URL: http://www.gnu.org/software/help2man Source: ftp://ftp.gnu.org/gnu/help2man/help2man-%{version}.tar.xz %{!?with_nls:BuildArch: noarch} BuildRequires: %{?scl_prefix_perl}perl(Getopt::Long) BuildRequires: %{?scl_prefix_perl}perl(POSIX) BuildRequires: %{?scl_prefix_perl}perl(Text::ParseWords) BuildRequires: %{?scl_prefix_perl}perl(Text::Tabs) BuildRequires: %{?scl_prefix_perl}perl(strict) %{?with_nls:BuildRequires: %{?scl_prefix_perl}perl(Locale::gettext) /usr/bin/msgfmt} %{?with_nls:BuildRequires: %{?scl_prefix_perl}perl(Encode)} %{?with_nls:BuildRequires: %{?scl_prefix_perl}perl(I18N::Langinfo)} Requires: %{?scl_prefix_perl}perl(:MODULE_COMPAT_%(%{?scl:scl enable %{scl_perl} '}eval "`perl -V:version`"; echo $version%{?scl:'})) Requires(post): /sbin/install-info Requires(preun): /sbin/install-info %description help2man is a script to create simple man pages from the --help and --version output of programs. Since most GNU documentation is now in info format, this provides a way to generate a placeholder man page pointing to that resource while still providing some useful information. %prep %setup -q -n help2man-%{version} %build %configure --%{!?with_nls:disable}%{?with_nls:enable}-nls --libdir=%{_libdir}/help2man %{?scl:scl enable %{scl} "} make %{?_smp_mflags} %{?scl:"} %install %{?scl:scl enable %{scl} "} make install_l10n DESTDIR=$RPM_BUILD_ROOT %{?scl:"} %{?scl:scl enable %{scl} "} make install DESTDIR=$RPM_BUILD_ROOT %{?scl:"} %find_lang %pkg_name --with-man %post /sbin/install-info %{_infodir}/help2man.info %{_infodir}/dir 2>/dev/null || : %preun if [ $1 -eq 0 ]; then /sbin/install-info --delete %{_infodir}/help2man.info \ %{_infodir}/dir 2>/dev/null || : fi %files -f %pkg_name.lang %doc README NEWS THANKS COPYING %{_bindir}/help2man %{_infodir}/* %{_mandir}/man1/* %if %{with nls} %{_libdir}/help2man %endif %changelog * Tue Apr 22 2014 John Doe <jdoe@example.com> - 1.44.1-1 - Built for h2m144 SCL.
4.4.3. Building the h2m144 Software Collection
- Install the rh-perl524-scldevel and rh-perl524-perl-macros packages that are part of the perl524 Software Collection.
- Build h2m144.spec and install the h2m144-runtime and h2m144-build packages.
- Install the rh-perl524-perl, rh-perl524-perl-Text-ParseWords and rh-perl524-perl-Getopt-Long packages, which are all build requirements for help2man.
- Build
help2man.spec
.
4.4.4. Testing the h2m144 Software Collection
- Install the h2m144-help2man package.
- Run the following command:
$
scl enable h2m144 'help2man bash'
- Verify that the output is similar to the following lines:
.\" DO NOT MODIFY THIS FILE! It was generated by help2man 1.44.1. .TH BASH, "1" "April 2014" "bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu)" "User Commands" .SH NAME bash, \- manual page for bash, version 4.1.2(1)-release (x86_64-redhat-linux-gnu) .SH SYNOPSIS .B bash [\fIGNU long option\fR] [\fIoption\fR] ... .SH DESCRIPTION GNU bash, version 4.1.2(1)\-release\-(x86_64\-redhat\-linux\-gnu) .IP bash [GNU long option] [option] script\-file ... .SS "GNU long options:" .HP \fB\-\-debug\fR
Chapter 5. Troubleshooting Software Collections
5.1. Error: line XX: Unknown tag: %scl_package software_collection_name
#
yum install scl-utils-build
5.2. scl command does not exist
#
yum install scl-utils
5.3. Unable to open /etc/scl/prefixes/software_collection_name
scl
command you are calling. Check the scl
command is correct and that you have not mistyped any of the arguments.
5.4. scl_source: command not found
#
yum update scl-utils
Appendix A. Getting More Information
A.1. Red Hat Developers
- Overview of Red Hat Software Collections on Red Hat Developers – The Red Hat Developers portal provides a number of tutorials to get you started with developing code using different development technologies. This includes the Node.js, Perl, PHP, Python, and Ruby Software Collection.
- Red Hat Developer Blog – The Red Hat Developer Blog contains up-to-date information, best practices, opinion, product and program announcements as well as pointers to sample code and other resources for those who are designing and developing applications based on Red Hat technologies.
A.2. Installed Documentation
- scl(1) – The man page for the scl tool for enabling Software Collections and running programs in Software Collection's environment.
- scl --help – General usage information for the scl tool for enabling Software Collections and running programs in Software Collection's environment.
- rpmbuild(8) – The man page for the rpmbuild utility for building both binary and source packages.
A.3. Accessing Red Hat Documentation
- Red Hat Software Collections 3.8 Release Notes – The Release Notes for Red Hat Software Collections 3.8 document the major features and contains other information about Red Hat Software Collections, a Red Hat offering that provides a set of dynamic programming languages, database servers, and various related packages.
- Red Hat Developer Toolset 12.1 User Guide – The User Guide for Red Hat Developer Toolset 12.1 contains information about Red Hat Developer Toolset, a Red Hat offering for developers on the Red Hat Enterprise Linux platform. Using Software Collections, Red Hat Developer Toolset provides current versions of the GCC compiler, GDB debugger and other binary utilities.
- Using Red Hat Software Collections 3.8 Container Images – This guide provides information on how to use container images based on Red Hat Software Collections. The available container images include applications, daemons, and databases. The images can be run on Red Hat Enterprise Linux 7 Server and Red Hat Enterprise Linux Atomic Host.
- Red Hat Enterprise Linux 7 Developer Guide – The Developer Guide for Red Hat Enterprise Linux 7 provides detailed description of Red Hat Developer Toolset features, as well as an introduction to Red Hat Software Collections, and information on libraries and runtime support, compiling and building, debugging, and profiling.
- Red Hat Enterprise Linux 7 System Administrator's Guide – The System Administrator's Guide for Red Hat Enterprise Linux 7 documents relevant information regarding the deployment, configuration, and administration of Red Hat Enterprise Linux 7.
- Red Hat Enterprise Linux 6 Developer Guide – The Developer Guide for Red Hat Enterprise Linux 6 provides detailed description of Red Hat Developer Toolset features, as well as an introduction to Red Hat Software Collections, and information on libraries and runtime support, compiling and building, debugging, and profiling.
- Red Hat Enterprise Linux 6 Deployment Guide – The Deployment Guide for Red Hat Enterprise Linux 6 documents relevant information regarding the deployment, configuration, and administration of Red Hat Enterprise Linux 6.
Appendix B. Revision History
Revision History | ||||
---|---|---|---|---|
Revision 4.2-0 | Fri Jun 09 2023 | |||
| ||||
Revision 4.1-9 | Tue May 23 2023 | |||
| ||||
Revision 4.1-8 | Mon Nov 15 2021 | |||
| ||||
Revision 4.1-7 | Mon Oct 11 2021 | |||
| ||||
Revision 4.1-6 | Thu Jun 03 2021 | |||
| ||||
Revision 4.1-5 | Mon May 03 2021 | |||
| ||||
Revision 4.1-4 | Tue Dec 01 2020 | |||
| ||||
Revision 4.1-3 | Tue Oct 29 2020 | |||
| ||||
Revision 4.1-2 | Tue May 26 2020 | |||
| ||||
Revision 4.1-1 | Tue Apr 21 2020 | |||
| ||||
Revision 4.1-0 | Tue Dec 10 2019 | |||
| ||||
Revision 4.0-9 | Mon Oct 28 2019 | |||
| ||||
Revision 4.0-8 | Tue Jun 04 2019 | |||
| ||||
Revision 4.0-7 | Wed Apr 10 2019 | |||
| ||||
Revision 4.0-6 | Thu Nov 01 2018 | |||
| ||||
Revision 4.0-5 | Wed Oct 17 2018 | |||
| ||||
Revision 4.0-4 | Thu Apr 12 2018 | |||
| ||||
Revision 4.0-3 | Fri Mar 16 2018 | |||
| ||||
Revision 4.0-2 | Tue Oct 17 2017 | |||
| ||||
Revision 4.0-1 | Thu Aug 31 2017 | |||
| ||||
Revision 3.10-0 | Mon Jun 5 2017 | |||
| ||||
Revision 3.9-0 | Thu Apr 20 2017 | |||
| ||||
Revision 3.8-0 | Wed Apr 05 2017 | |||
| ||||
Revision 3.7-0 | Wed Jan 25 2017 | |||
| ||||
Revision 3.6-0 | Wed Nov 02 2016 | |||
| ||||
Revision 3.5-0 | Wed Oct 12 2016 | |||
| ||||
Revision 3.4-0 | Mon May 23 2016 | |||
| ||||
Revision 3.3-0 | Tue Apr 26 2016 | |||
| ||||
Revision 3.2-0 | Wed Nov 04 2015 | |||
| ||||
Revision 3.1-0 | Tue Oct 06 2015 | |||
| ||||
Revision 3.0-2 | Tue May 19 2015 | |||
| ||||
Revision 3.0-1 | Wed Apr 22 2015 | |||
| ||||
Revision 2.2-4 | Fri Nov 21 2014 | |||
| ||||
Revision 2.2-2 | Thu Oct 30 2014 | |||
| ||||
Revision 2.2-1 | Tue Oct 07 2014 | |||
| ||||
Revision 2.2-0 | Tue Sep 09 2014 | |||
| ||||
Revision 2.1-29 | Wed Jun 04 2014 | |||
| ||||
Revision 2.1-21 | Thu Mar 20 2014 | |||
| ||||
Revision 2.1-18 | Tue Mar 11 2014 | |||
| ||||
Revision 2.1-8 | Tue Feb 11 2014 | |||
| ||||
Revision 2.0-12 | Tue Sep 10 2013 | |||
| ||||
Revision 2.0-8 | Tue Aug 06 2013 | |||
| ||||
Revision 2.0-3 | Tue May 28 2013 | |||
| ||||
Revision 1.0-2 | Tue Apr 23 2013 | |||
| ||||
Revision 1.0-1 | Tue Jan 22 2013 | |||
| ||||
Revision 1.0-2 | Thu Nov 08 2012 | |||
| ||||
Revision 1.0-1 | Wed Oct 10 2012 | |||
| ||||
Revision 1.0-0 | Tue Jun 26 2012 | |||
| ||||
Revision 0.0-2 | Tue Apr 10 2012 | |||
| ||||
Revision 0.0-1 | Tue Mar 06 2012 | |||
|