Edition 1.0
yum install scl-utils scl-utils-buildsoftware_collection_1, run the following command:
yum install software_collection_1 scl --list sclactionsoftware_collection_1software_collection_2command
--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.
%_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).
software_collection_1 and software_collection_2:
%_scl_prefix macro in the spec file, as in the following example:
%global _scl_prefix /opt/providerprovider is the provider (vendor) name registered, where applicable, with the Linux Foundation and the subordinated Linux Assigned Names and Numbers Authority (LANANA), in conformance with the Filesystem Hierarchy Standard.
/opt/provider/prefix-application-version/
provider part, which defines the provider's name, and
_), as in the following example:
myorganization_ruby193
myorganization is the provider's name, and ruby193 is the name of the Software Collection.
prefix part, discussed in Section 2.4, “The Software Collection Prefix”, and
-), as in the following example:
myorganization_ruby193-foreman-1.1
myorganization_ruby193 is the prefix, and foreman-1.1 is the name and version number of the application.
/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
name-runtimemyorganization_ruby193, then the runtime subpackage macro is expanded to:
myorganization_ruby193-runtime
name-buildmyorganization_ruby193, then the build subpackage macro is expanded to:
myorganization_ruby193-build
name-scldevelmyorganization_ruby193, then the scldevel subpackage macro is expanded to:
myorganization_ruby193-scldevel
Requires: scl-utils-build to the build subpackage.
macros.%{scl}-config file in the build subpackage.
enable scriptlet.
PATH=%{_bindir}\${PATH:+:\${PATH}} to the 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.
%global scl software_collection %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. %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}\${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 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 filesystem %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.
|
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.
|
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/
|
%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 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
%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.
--- 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/*
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:Requires: %{scl}-runtime}
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
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.specrpmbuild -ba package.spec to build the Software Collection, specify the following in the package.spec file:
BuildRequires: software_collection-buildsoftware_collection is the name of the Software Collection.
rpmbuild -ba package.spec --define 'scl name' command to build the Software Collection, you can have the build subpackages created by rebuilding the Software Collection metapackage. Note that you need to have the scl-utils-build package installed on your system, otherwise rebuilding the Software Collection metapackage with the rpmbuild command will fail.
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}
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/rubyscl-ruby and allows the user to run rubyscl-ruby command instead of scl enable rubyscl 'ruby command':
#!/bin/bash COMMAND="ruby $@" scl enable rubyscl "$COMMAND"
/usr/bin/ directory where the wrappers would otherwise be installed.
%install section of the spec file as follows:
%install install -p -c -m 644 %{SOURCE2} $RPM_BUILD_ROOT%{?scl:%_root_sysconfdir}%{!?scl:%_sysconfdir}/rc.d/init.d/%{?scl_prefix}service_name
%{?scl_prefix}service_nameLD_LIBRARY_PATH environment variable in the enable scriptlet as follows:
export LD_LIBRARY_PATH=%{_libdir}${LD_LIBRARY_PATH:+:${LD_LIBRARY_PATH}}
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.
/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.
%{?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.
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 3.1, “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 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 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).
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.shpc-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_filesSOURCE2: %{?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/
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.shpc-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_filesSOURCE2: %{?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 manual pages from the enabled Software Collection, update the MANPATH environment variable with the paths to the manual 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 manual 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 manual pages are visible to the system even if the Software Collection is disabled.
man command on the system to display manual pages from the disabled Software Collection, update the MANPATH environment variable with the paths to the manual pages associated with the 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.shmanpage.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/
crontab file for your Software Collection in the /etc/cron.d/ directory with the Software Collection's name.
%{?scl_prefix}crontabcrontab file follow the standard crontab file format, as in the following example:
0 1 * * Sun root scl enablesoftware_collection'/opt/'provider/software_collection/root/usr/bin/cron_job_name
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.
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/software_collection/root/var/log/ directory. Consider creating the log files outside of the Software Collection file system hierarchy, that is in the /var/log/ system directory. When using the system directory, all log files are stored in the same location, which makes it easier for users to locate and manage them.
/etc/logrotate.d/.
%{?scl_prefix}logrotatelogrotate 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/
/opt/provider/software_collection/ file system hierarchy, you can avoid any possible conflicts with the system versions of the applications or services that can be on the system.
/var/lock/ instead of the Software Collection's directory /opt/provider/software_collection/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.
/opt/provider/software_collection/var/lock/.
/opt/provider/software_collection/ file system hierarchy, you can avoid any possible conflicts with the system versions of the configuration files that can be present on the system.
/opt/provider/software_collection/, then ensure that you properly configure an alternative location for the configuration files. For many programs, this can be usually done at build or installation time.
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/usrrestorecon -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/usrrestorecon -R -v /opt/provider/software_collection_1/root/usrselinuxenabled && 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.
semanage -e command, which substitutes the source path for the destination path during labeling, is not supported in Enterprise Linux 5.
%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, in Red Hat Software Collections, the ruby193-scldevel subpackage cannot be installed when there is the ruby200-scldevel subpackage installed.
%{!?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 includes the following lines:
%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.
XX: Unknown tag: %scl_package software_collection_name#yum install scl-utils-build
#yum install scl-utils
software_collection_namescl command you are calling. Check the scl command is correct and that you have not mistyped any of the arguments.
software_collection_name Software Collection is properly installed on the system. For more information, see Section 1.5, “Listing Installed Software Collections”.
#yum update scl-utils
yum install spec2scl command.
| Revision History | ||||
|---|---|---|---|---|
| Revision 1-5 | Mon 08 Jun 2015 | |||
| ||||
| 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 | |||
| ||||