{% extends "section_docs_guide.html" %}} {% block title %}Packaging Guide{% endblock %} {% block content %}
With RPM, you can:
Software Collections:
#
yum install scl-utils scl-utils-build
software_collection_1
, run the following command:
#
yum install software_collection_1
scl --list
scl --list software_collection_1
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:
--version
option in the Software Collection named software_collection_1, execute the following command:
scl enable software_collection_1 'perl --version'
scl enable software_collection_1 software_collection_2 bash
cat cmd | scl enable software_collection_1 -
cmd
file, in the environment of the Software Collection named software_collection_1.
$X_SCLS
environment variable by running the following command:
echo $X_SCLS
software_collection_1
, run the following command:
yum remove software_collection_1\*
yum remove
command to remove the scl utility.
When creating a new Software Collection for your application:
%_scl_prefix
macro in the Software Collection spec file. For more information, see Section 2.3, “The Software Collection Root Directory”.
/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).
%_scl_prefix
macro in the spec file, as in the following example:
%global _scl_prefix /opt/provider
/opt/provider/prefix-application-version/
-
), as in the following example:
myorganization-ruby193
rh
as the provider's name. For example:
rh-ruby23
-
), as in the following example:
myorganization-ruby193-foreman-1.1
/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.
myorganization-ruby193
, then the main package macro is expanded to:
myorganization-ruby193
myorganization-ruby193
, then the runtime subpackage macro is expanded to:
myorganization-ruby193-runtime
myorganization-ruby193
, then the build subpackage macro is expanded to:
myorganization-ruby193-build
myorganization-ruby193-build
subpackage are shown below:
$
cat /etc/rpm/macros.ruby193-config
%scl myorganization-ruby193
myorganization-ruby193
, then the syspaths subpackage macro is expanded to:
myorganization-ruby193-syspaths
myorganization-ruby193
, then the scldevel subpackage macro is expanded to:
myorganization-ruby193-scldevel
When creating a new metapackage:
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.
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”.
Requires: scl-utils-build
to the build subpackage.
enable
scriptlet.
%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.
%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.
macros.%{scl}-config
file in the build subpackage.
%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 %scl_package %scl %global _scl_prefix /opt/myorganization 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
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.
Table 2.1. Software Collection Specific Macros
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
|
_root
as a prefix.
Table 2.2. Software Collection Non-Specific Macros
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/
|
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”.
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
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”.
enable
scriptlet to redefine the environment variable:
export GEM_PATH="\${GEM_PATH:=%{gem_dir}:\`scl enable %{scl_ruby} -- ruby -e "print Gem.path.join(':')"\`}"
GOPATH
environment variable specifies the location of Go source and binary files. Include the following in the enable
scriptlet to redefine the environment variable:
export GOPATH="%{gopath}\${GOPATH:+:\${GOPATH}}"
JAVACONFDIRS
environment variable is used to specify the location of the java.conf
configuration file. Include the following in the enable
scriptlet to redefine the environment variable:
export JAVACONFDIRS="%{_sysconfdir}/java\${JAVACONFDIRS:+:}\${JAVACONFDIRS:-}"
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 the enable
scriptlet to redefine the environment variable:
export PERL5LIB="%{_scl_root}%{perl_vendorlib}\${PERL5LIB:+:\${PERL5LIB}}"
PYTHONPATH
environment variable specifies the location of custom Python libraries. Include the following in the enable
scriptlet to redefine the environment variable:
export PYTHONPATH="%{_scl_root}%{python_sitearch}:%{_scl_root}%{python_sitelib}\${PYTHONPATH:+:}\${PYTHONPATH:-}"
CPATH
environment variable specifies include paths for the GCC compiler to use. Include the following in the enable
scriptlet to redefine the environment variable:
export CPATH="%{_includedir}\${CPATH:+:\${CPATH}}"
INFOPATH
environment variable specifies directories that contain Info files. Include the following in the enable
scriptlet to redefine the environment variable:
export INFOPATH="%{_infodir}\${INFOPATH:+:\${INFOPATH}}"
LD_LIBRARY_PATH
environment variable specifies the location of libraries. For more information, see Section 3.5, “Software Collection Library Support”.
enable
scriptlet to redefine the environment variable:
export LD_LIBRARY_PATH="%{_libdir}\${LD_LIBRARY_PATH:+:\${LD_LIBRARY_PATH}}"
LIBRARY_PATH
environment variable specifies the location of special linker files or ordinary libraries for GCC to use. Include the following in the enable
scriptlet to redefine the environment variable:
export LIBRARY_PATH="%{_libdir}\${LIBRARY_PATH:+:\${LIBRARY_PATH}}"
MANPATH
environment variable specifies the location of man pages. For more information, see Section 3.7, “Software Collection MANPATH Support”.
enable
scriptlet to redefine the environment variable:
export MANPATH="%{_mandir}:\${MANPATH:-}"
PATH
environment variable specifies the location of binary files. Include the following in the enable
scriptlet to redefine the environment variable:
export PATH="%{_bindir}:%{_sbindir}\${PATH:+:\${PATH}}"
PCP_DIR
environment variable specifies the location of files and directories used by PCP. Include the following in the enable
scriptlet to redefine the environment variable:
export PCP_DIR="%{_scl_root}"
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”.
enable
scriptlet to redefine the environment variable:
export PKG_CONFIG_PATH="%{_libdir}/pkgconfig\${PKG_CONFIG_PATH:+:\${PKG_CONFIG_PATH}}"
XDG_CONFIG_DIRS
environment variable specifies the location of desktop configuration files according to the freedesktop.org specification. Include the following in the enable
scriptlet to redefine the environment variable:
export XDG_CONFIG_DIRS="%{_sysconfdir}/xdg:\${XDG_CONFIG_DIRS:-/etc/xdg}"
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.
enable
scriptlet to redefine the environment variable:
export XDG_DATA_DIRS="%{_datadir}:\${XDG_DATA_DIRS:-/usr/local/share:%{_root_datadir}}"
--- a/less.spec +++ b/less.spec @@ -1,10 +1,13 @@ +%{?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/*
Procedure 2.1. Converting tags and macro definitions
%scl_package
macro to the spec file. Place the macro in front of the spec file preamble as follows:
%{?scl:%scl_package package_name}
%pkg_name
macro in the spec file preamble in case the package is not built for the Software Collection:
%{!?scl:%global pkg_name %{name}}
%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.
Name
tag in the spec file preamble as follows:
Name: %{?scl_prefix}package_name
Requires
and BuildRequires
tags with %{?scl_prefix}
as follows:
Requires: %{?scl_prefix}ifconfig
Requires
or BuildRequires
. If you need to depend on a package that could be updated by the system, consider including that package in your Software Collection, or remember to rebuild your Software Collection when the system package updates.
BuildRequires
or Requires
tags in the spec file:
%{?scl:Requires: %scl_runtime}
Obsoletes
, Conflicts
and BuildConflicts
tags with %{?scl_prefix}
. This is to ensure that the Software Collection can be used to deploy new packages to older systems without having the packages specified, for example, by Obsolete
removed from the base system installation. For example:
Obsoletes: %{?scl_prefix}lesspipe < 1.0
Provides
tag with %{?scl_prefix}
, as in the following example:
Provides: %{?scl_prefix}more
-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}
%prep
, %build
, %install
, %check
, %pre
, and %post
sections of a conventional spec file.
%name
with %pkg_name
. Most importantly, this includes adjusting the %setup
macro.
%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}
%setup
macro is required and that you must always use the macro with the -n
option to successfully build your Software Collection.
%_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}
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.
%{?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}
set -e
in the script so that the script behavior is consistent regardless of whether the script is executed in the rpm
shell or the scl
environment.
%pretrans
, %pre
,
%post
, %postun
, %posttrans
,
%triggerin
, %triggerun
, and %triggerpostun
.
scl enable
functionality in those scripts, you are advised to start with an empty environment to avoid any unintentional collisions with the base system installation.
env -i -
before enabling the Software Collection, as in the following example:
%posttrans %{?scl:env -i - scl enable %{scl} - << \EOF} %vagrant_plugin_register %{vagrant_plugin_name} %{?scl:EOF}
/usr/share
with %{_datadir}
. This is needed because the $RPM_BUILD_ROOT
variable and the %{build_root}
macro are not relocated by the scl
macro.
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:
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'
Provides
or Requires
:
%{?scl:%filter_from_provides s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_from_requires s|pkgconfig|%{?scl_prefix}pkgconfig|g} %{?scl:%filter_setup}
Important
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.
%{?scl:%{_root_sysconfdir}}%{!?scl:%{_sysconfdir}}/rpm/
directory, which corresponds to the /etc/rpm/
directory for conventional packages. When shipping macro files, ensure that:
.%{scl}
to their names so that they do not conflict with the files from the base system installation.
%__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
).
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
%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.
#!/usr/bin/env example
/usr/bin/env
program to run the interpreter.
/usr/bin/env
program, as expected.
$PATH
environment variable is redefined properly in the enable
scriptlet, the example interpreter is found in the Software Collection file system hierarchy, as expected.
#!/usr/bin/example
/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.
$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.
find %{buildroot} -type f | \ xargs sed -i -e '1 s"^#!/usr/bin/example"#!%{?_scl_root}/usr/bin/example"'
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
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}
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
rpmbuild -ba package.spec --define 'scl name'
command.
rpmbuild
command will fail.
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
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.
Table 3.1. Changed Values for Software Collection Macros
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}
|
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 ...
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
%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/
.
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
#
yum install environment-modules
/usr/share/Modules/bin/createmodule.sh
script to convert your Software Collection's enable
scriptlet into an environment module:
/usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet
enable
scriptlet you want to convert.
/usr/share/Modules/bin/createmodule.sh /path/to/enable/scriptlet
in the %pre
section of your Software Collection metapackage, below the code generating your enable
scriptlet.
enable
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.
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.
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
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.
/opt/provider/%{scl}
file system hierarchy needs to be used, because gdb does not work with wrapper shell scripts.
/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.
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
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
Procedure 3.2. Configuring an environment for services on Red Hat Enterprise Linux 6
/opt/provider/software_collection/service-environment
with the following content:
[SCLNAME]_SCLS_ENABLED="software_collection"
%scl_name
macro.
source /opt/provider/software_collection/service-environment
/opt/provider/
file system hierarchy. Prefix these commands with scl enable $[SCLNAME]_SCLS_ENABLED
, similarly to when you run a command in the Software Collection environment.
/usr/bin/daemon_binary --argument-1 --argument-2
scl enable $[SCLNAME]_SCLS_ENABLED -- /usr/bin/daemon_binary --argument-1 --argument-2
su
or runuser
, also clear environment variables. Thus, if these commands are used in the SysV init script, enable your Software Collection again after running these commands.
su - user_name -c '/usr/bin/daemon_binary --argument-1 --argument-2'
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
/opt/provider/software_collection/service-environment
with the following content:
[SCLNAME]_SCLS_ENABLED="software_collection"
%scl_name
macro.
EnvironmentFile=/opt/provider/software_collection/service-environment
ExecStartPre
, ExecStart
, and similar directives with scl 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
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.
/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
%{?scl_prefix}libs.conf
and adjust the spec file configuration accordingly:
SOURCE2: %{?scl_prefix}libs.conf
%{?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/
/usr/lib64/
directory that is part of the Software Collection software_collection_1 is included in the list.
%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/
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.
%__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.
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}
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.
%{?scl_prefix}pc-libdir.sh
pc-libdir.sh
short script that modifies the PKG_CONFIG_PATH
variable to refer to your .pc files:
export PKG_CONFIG_PATH="%{_libdir}/pkgconfig:/opt/provider/software_collection/path/to/your/pc_files"
SOURCE2: %{?scl_prefix}pc-libdir.sh
/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}
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.
%{?scl_prefix}pc-datadir.sh
pc-datadir.sh
short script that modifies the PKG_CONFIG_PATH
variable to refer to your .pc files:
export PKG_CONFIG_PATH="%{_datadir}/pkgconfig:/opt/provider/software_collection/path/to/your/pc_files"
SOURCE2: %{?scl_prefix}pc-datadir.sh
/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/
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
MANPATH
environment variable, create a custom script /etc/profile.d/name.sh
. The script is preloaded when a shell is started on the system.
%{?scl_prefix}manpage.sh
manpage.sh
short script that modifies the MANPATH
variable to refer to your man path directory:
export MANPATH="/opt/provider/software_collection/path/to/your/man_pages:${MANPATH}"
SOURCE2: %{?scl_prefix}manpage.sh
/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.8. Running periodic tasks with cronjobs
crontab
file for your Software Collection in the /etc/cron.d/
directory with the Software Collection's name.
%{?scl_prefix}crontab
crontab
file follow the standard crontab
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
'
/opt/provider/software_collection/root/usr/bin/cron_job_name
is the command you want to periodically run.
SOURCE2: %{?scl_prefix}crontab
/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/
/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”.
Procedure 3.9. Managing log files with logrotate
/etc/logrotate.d/
.
%{?scl_prefix}logrotate
logrotate
file follow the standard logrotate
file format as follows:
/opt/provider/software_collection/var/log/your_application_name.log { missingok notifempty size 30k yearly create 0600 root root }
SOURCE2: %{?scl_prefix}logrotate
/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/
/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”.
/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”.
/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.
/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.
/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”.
Requires
, which can be found in your kernel module spec file, includes the kernel version and revision (in the format kernel-version-revision
).
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.
%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.
%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}
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
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.
Table 3.2. Provides in Red Hat Enterprise Linux 7
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.
Table 3.3. Provide in Red Hat Enterprise Linux 6
Software Collection package
|
Provide
|
---|---|
${software_collection_1}
| scl-package(software_collection_1)
|
Procedure 4.1. Providing your own scldevel subpackage
%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.
Provides: scldevel(%{scl_name_base})
during the build of packages of dependent Software Collections. This will ensure availability of a version of the %{scl_name_base}
Software Collection and its macros, as specified in the following step.
%install
section of your Software Collection's metapackage, create the macros.%{scl_name_base}-scldevel
file that is part of the scldevel subpackage and contains:
cat >> %{buildroot}%{_root_sysconfdir}/rpm/macros.%{scl_name_base}-scldevel << EOF %%scl_%{scl_name_base} %{scl} %%scl_prefix_%{scl_name_base} %{scl_prefix} EOF
%{scl_name_base}
name, the provided macros.%{scl_name_base}-scldevel
files must conflict. This is to disallow installing multiple versions of the %{scl_name_base}
Software Collections. For example, the ruby193-scldevel subpackage cannot be installed when there is the ruby200-scldevel subpackage installed.
Procedure 4.2. Using your own scldevel subpackage in a dependent Software Collection
%{!?scl_ruby:%global scl_ruby ruby200} %{!?scl_prefix_ruby:%global scl_prefix_ruby %{scl_ruby}-}
%{?scl_prefix_ruby}
BuildRequires: %{scl_prefix_ruby}scldevel
%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
%package build
part of the metapackage's spec file:
%package build Summary: Package shipping basic build configuration Requires: %{scl_prefix_ruby}scldevel
Requires: %{scl_prefix_ruby}scldevel
ensures that macros are available in all packages of the Software Collection.
Requires
only makes sense in specific use cases, such as where packages in a dependent Software Collection use macros provided by the scldevel subpackage.
%scl_package_override()
, which allows for easier packaging of your own dependent Software Collection.
vt191
and contains the versiontools Python package version 1.9.1.
BuildRequires: %{scl_prefix_python}scldevel
%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.
site-packages
directory set up properly, use the value of the %python27python_sitelib
macro and replace python27
with vt191
. 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
/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.
Requires: %{scl_prefix_python}scldevel
enable
scriptlet for the vt191 Software Collection uses the following line:
. scl_source enable %{scl_python}
scl enable vt191 command
instead of scl enable python27 vt191 command
to run command in the Software Collection environment.
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.
BuildRequires
tags are prefixed with %{?scl_prefix_python}
instead of %{scl_prefix}
.
%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.
vt191.spec
and install the vt191-runtime and vt191-build packages.
python-versiontools.spec
.
$
scl enable vt191 "python -c 'import versiontools; print(versiontools.__file__)'"
/opt/rh/vt191/root/usr/lib/python2.7/site-packages/versiontools/__init__.pyc
rh
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.
BuildRequires: %{scl_prefix_ruby}scldevel BuildRequires: %{scl_prefix_ruby}rubygems-devel
%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.
%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.
%package runtime Requires: %{scl_prefix_ruby}runtime
%package build Requires: %{scl_prefix_ruby}scldevel
enable
scriptlet for the rh-ror42 Software Collection contains the following line:
. scl_source enable %{scl_ruby}
scl enable rh-ror42 command
instead of scl enable rh-ruby23 rh-ror42 command
to run command in the Software Collection environment.
%{scl_ror}
and %{scl_prefix_ror}
macros, which can be used to extend the rh-ror42 Software Collection.
%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.
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.
rh-ror42.spec
and install the ror42-runtime and ror42-build packages.
rubygem-bcrypt.spec
.
$
scl enable rh-ror42 -- ruby -r bcrypt -e "puts BCrypt::Password.create('my password')"
$2a$10$s./ReniLY.wXPHVBQ9npoeyZf5KzywfpvI5lhjG6Ams3u0hKqwVbW
Important
BuildRequires: %{scl_prefix_perl}scldevel
%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.
Requires: %{scl_prefix_perl}scldevel
enable
scriptlet for the h2m144 Software Collection contains the following line:
. scl_source enable %{scl_perl}
scl enable h2m144 command
instead of scl enable rh-perl524 h2m144 command
to run command in the Software Collection environment.
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.
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.
help2man.spec
.
$
scl enable h2m144 'help2man bash'
.\" 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
#
yum install scl-utils-build
#
yum install scl-utils
scl
command you are calling. Check the scl
command is correct and that you have not mistyped any of the arguments.
#
yum update scl-utils
yum install spec2scl
command.
Revision History | ||||
---|---|---|---|---|
Revision 2-7 | Thu May 17 2018 | |||
| ||||
Revision 2-6 | Wed Aug 23 2017 | |||
| ||||
Revision 2-5 | Mon Jan 30 2017 | |||
| ||||
Revision 2-4 | Mon 21 Nov 2016 | |||
| ||||
Revision 2-3 | Mon 08 Jun 2015 | |||
| ||||
Revision 2-2 | Fri 24 Apr 2015 | |||
| ||||
Revision 2-1 | Thu 05 Mar 2015 | |||
| ||||
Revision 2-0 | Thu Nov 06 2014 | |||
| ||||
Revision 1-4 | Fri Jul 11 2014 | |||
| ||||
Revision 1-3 | Sun Mar 23 2014 | |||
| ||||
Revision 1-2 | Wed Sep 18 2013 | |||
| ||||
Revision 1-1 | Mon Feb 18 2013 | |||
| ||||
Revision 1-0 | Tue Jun 19 2012 | |||
| ||||
Revision 0.0-0 | Thu Feb 23 2012 | |||
|