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.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