Este conteúdo não está disponível no idioma selecionado.
3.3. Providing syspaths Subpackages
In order to use a Software Collection's packages, users need to perform certain tasks that differ from when using conventional RPM packages. For example, they need to use an
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.
A recommended solution to address the problems described above is to use syspaths subpackages. The basic idea is to allow users to consume different versions of the same package without affecting the base system installation, but with the option to use the Software Collection packages as if they were conventional RPM packages, making the Software Collection easier to use.
The optional syspaths subpackages (such as rh-mariadb102-syspaths) provide shell wrappers and symbolic links that are installed into the standard path (typically,
/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.
Using syspaths subpackages avoids the need for adjusting scripts in the Software Collection packages to make those scripts easier to use. Keep in mind that syspaths subpackages do conflict with the packages from the base system installation, so the conventional packages cannot be installed together with the syspaths subpackages. If that is a concern, consider employing a container-based technology to isolate the syspaths subpackages from the base system installation.
3.3.1. Naming syspaths Subpackages
For each Software Collection that utilizes the concept of a syspaths subpackage, there are typically multiple syspaths subpackages provided. syspaths subpackages are made available for each package with a file that can be provided with a wrapper or a symbolic link.
On top of that, there is a Software Collection metapackage's subpackage named software_collection_1-syspaths, where software_collection_1 is the name of the Software Collection. The software_collection_1-syspaths subpackage requires other syspaths subpackages included the Software Collection. Installing the software_collection_1-syspaths subpackage thus results in installing all the other syspaths packages.
For example, if you want to include wrappers for a binary file
binary_1 included in the software_collection_1-package_1 package and a binary file binary_2 included in the software_collection_1-package_2 package, then create the following three syspaths subpackages in the software_collection_1 Software Collection:
software_collection_1-syspaths software_collection_1-package_1-syspaths software_collection_1-package_2-syspaths
3.3.2. Files Included in syspaths Subpackages
The files suitable for inclusion in syspaths subpackages are executable shell wrappers for binaries that users interact with.
The following is an example of a wrapper for a binary file
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" "$@"
When you install this wrapper in
/usr/bin/binary_1 and make it executable, users can then simply run the binary_1 command without the need to prefix it with scl enable software_collection_1. The wrapper installed in /usr/bin/ sets up the correct environment and executes the target binary located withing the /opt/provider/%{scl} file system hierarchy.
3.3.3. Limitations of syspaths Wrappers
The fact that syspaths wrappers are shell scripts means that users cannot perform every possible task with the wrappers as with the target binary. For example, when debugging binaries using gdb, the full path pointing to the
/opt/provider/%{scl} file system hierarchy needs to be used, because gdb does not work with wrapper shell scripts.
3.3.4. Symbolic Links in syspaths Subpackages
Other than wrappers for binary files, there are more files that are suitable for installation outside of the
/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.
A good idea is to name the symbolic link
/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.
The same applies to configuration files, the goal is to make symbolic links easy to discover under the
/etc directory.
3.3.5. Services Without a Prefix
systemd and SysV init services are popular examples of user interaction with daemon services. In general, users do not need to include
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).
syspaths subpackages allow users to use the conventional names of the services, such as
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.
For example, a service
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
Or, in the case of a systemd unit file:
/usr/lib/systemd/system/service_1 -> /usr/lib/systemd/system/software_collection_1-service_1
