このコンテンツは選択した言語では利用できません。
Chapter 3. Advanced Topics
This chapter discusses advanced topics on packaging Software Collections.
3.1. Using Software Collections over NFS
In some environments, the requirement is often to have a centralized model for how applications and tools are distributed rather than allowing users to install the application or tool version they prefer. In this way, NFS is the common method of mounting centrally managed software.
You need to define a Software Collection macro
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.
If you do not need support for Software Collections over NFS, using
nfsmountable
is optional but recommended.
To define the
nfsmountable
macro, ensure that the Software Collection metapackage spec file contains the following lines:
%global nfsmountable 1 %scl_package %scl
As shown above, the
nfsmountable
macro must be defined before defining the %scl_package
macro. This is because the %scl_package
macro redefines the _sysconfdir
, _sharedstatedir
, and _localstatedir
macros depending on whether the nfsmountable
macro has been defined or not. The values that nfsmountable
changes for the redefined macros are detailed in the following table.
Macro
|
Original definition
|
Expanded value for the original definition
|
Changed definition
|
Expanded value for the changed definition
|
---|---|---|---|---|
_sysconfdir
|
%{_scl_root}/etc
|
/opt/provider/%{scl}/root/etc
|
%{_root_sysconfdir}%{_scl_prefix}/%{scl}
|
/etc/opt/provider/%{scl}
|
_sharedstatedir
|
%{_scl_root}/var/lib
|
/opt/provider/%{scl}/root/var/lib
|
%{_root_localstatedir}%{_scl_prefix}/%{scl}/lib
|
/var/opt/provider/%{scl}/lib
|
_localstatedir
|
%{_scl_root}/var
|
/opt/provider/%{scl}/root/var
|
%{_root_localstatedir}%{_scl_prefix}/%{scl}
|
/var/opt/provider/%{scl}
|
3.1.1. Changed Directory Structure and File Ownership
The
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.
For example, a directory structure of a Software Collection named software_collection with the
nfsmountable
macro defined looks as follows:
$
rpmbuild -ba software_collection.spec --define 'scl software_collection'
...$
rpm -qlp software_collection-runtime-1-1.el6.x86_64
/etc/opt/provider/software_collection /etc/opt/provider/software_collection/X11 /etc/opt/provider/software_collection/X11/applnk /etc/opt/provider/software_collection/X11/fontpath.d ... /opt/provider/software_collection/root/usr/src /opt/provider/software_collection/root/usr/src/debug /opt/provider/software_collection/root/usr/src/kernels /opt/provider/software_collection/root/usr/tmp /var/opt/provider/software_collection /var/opt/provider/software_collection/cache /var/opt/provider/software_collection/db /var/opt/provider/software_collection/empty ...
3.1.2. Registering and Deregistering Software Collections
In case a Software Collection is shared over NFS but not locally installed on your system, you need to make the scl tool aware of it by registering that Software Collection.
Registering a Software Collection is done by running the
scl register
command:
$
scl register /opt/provider/software_collection
where /opt/provider/software_collection is the absolute path to the file system hierarchy of the Software Collection you want to register. The path's directory must contain the
enable
scriptlet and the root/
directory to be considered a valid Software Collection file system hierarchy.
Deregistering a Software Collection is a reverse operation that you perform when you no longer want the scl tool to be aware of a registered Software Collection.
Deregistering a Software Collection is done by calling a
deregister
scriptet when running the scl
command:
$
scl deregister software_collection
where software_collection is the name of the Software Collection you want to deregister.
3.1.2.1. Using (de)register Scriptlets in a Software Collection Metapackage
You can specify (de)register scriptlets in a Software Collection metapackage similarly to how enable scriptlets are specified. When specifying the scriptets, remember to explicitly include them in the
%file
section of the metapackage spec file.
See the following sample code for an example of specifying (de)register scriptets:
%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
In the register scriptlet, you can optionally specify the commands you want to run when registering the Software Collection, for example, commands to create files in
/etc/opt/
or /var/opt/
.