Red Hat/CentOS Software Collections (SCL)

By Paul Heinlein | Aug 29, 2016

Red Hat promises software compatibility for the life of any given RHEL release. It will not upgrade major applications mid-release. For example, if RHEL 6.0 contains PostgreSQL 8.4, RHEL 6.7 cannot move to PostgreSQL 9.4. Too many applications will break.

Yet some customers require the upgraded software. By way of an answer, Red Hat and the CentOS project have published what are called Software Collections (SCL). Packages provided in the SCL repositories typically provide newer versions of software that play a key role in the Linux world: Python, Apache, PostgreSQL, MySQL, gcc, etc.

Accessing SCL Repositories

Red Hat Enterprise Linux (RHEL) and CentOS have different ways of subscribing to yum repositories.


RHEL uses the subscription-manager utility:

# for RHEL 6
subscription-manager repos --enable rhel-6-server-optional-rpms
subscription-manager repos --enable rhel-server-rhscl-6-rpms

# for RHEL 7
subscription-manager repos --enable rhel-7-server-optional-rpms
subscription-manager repos --enable rhel-server-rhscl-7-rpms

You’ll have to contact your local licensing guru if those repositories aren’t visible from your host(s).


Use yum to make SCL repositories available on a CentOS machine:

# CentOS 6 and 7
yum install centos-release-scl

Listing Packages

The SCL repositories have a lot of packages, but you may be interested to see everything that’s offered. I suggest piping the output of the following commands to less or your favorite pager to ease the reading.

# RHEL 6
yum --disablerepo='*' --enablerepo='rhel-server-rhscl-6-rpms' list available

# RHEL 7
yum --disablerepo='*' --enablerepo='rhel-server-rhscl-7-rpms' list available

# CentOS 6 and 7
yum --disablerepo='*' \
    --enablerepo='centos-sclo-rh' \
    --enablerepo='centos-sclo-sclo' \
    list available

Taking the Road Less Traveled

To avoid any system-wide conflicts, SCL packages are installed in /opt/rh. This allows, for instance, you to install Python 3.5 on a CentOS 7 machine without removing or interfering with Python 2.7, which is used by roughly one gazillion administration applications crucial to the system’s functioning.

Since SCL packages are off the beaten path, people wanting to use them need to upgrade a variety of environment variables: PATH, LD_LIBRARY_PATH, MANPATH, etc. There are two main ways to do this.

Use a subshell

There’s a command-line tool, /usr/bin/scl, that eases access to these packages. It will get installed via the scl-utils package the first time you install an SCL rpm. See the scl(1) man page for full usage.

In the session below, I’ve installed the rh-python35 package on a CentOS 7 machine. The default python is version 2.7.5. When I enable the rh-python35 package using scl, I gain access to Python 3.5.1.

[heinlein ~]$ scl --list
[heinlein ~]$ echo $PATH
[heinlein ~]$ which python && python -V
Python 2.7.5
[heinlein ~]$ scl enable rh-python35 bash
[heinlein ~]$ echo $PATH
[heinlein ~]$ which python && python -V
Python 3.5.1
[heinlein ~]$ exit
[heinlein ~]$ which python && python -V
Python 2.7.5

The upside to this approach is that your permanent shell environment isn’t cluttered with /opt/rh paths. The downside is that the subshell doesn’t necessarily have access to your normal shell aliases, functions, etc.

Source the package-provided enable script

SCL packages provide shell scripts that define the environment variables necessary for using the included applications. You can find them in the filesystem as /opt/rh/<<package name>>/enable. It’s easy to source the enable script directly into your working environment.

[heinlein ~]$ which python && python -V
Python 2.7.5
[heinlein ~]$ source /opt/rh/rh-python35/enable
[heinlein ~]$ which python && python -V
Python 3.5.1

The upside to this approach is that all your normal shell conveniences are available. The downside is that you’ll have to logout (or do some extensive variable editing) to restore your pristine environment.

Conquering your daemons

There’s an added twist when the SCL package installs a daemon. How does it get started? I don’t have a definitive answer for all the packages, but from what I’ve seen, SCL init scripts work just fine.

For instance, I recently installed the rh-postgres94 package on a RHEL 6 host. Activating the daemon was easy:

chkconfig rh-postgresql94-postgresql on
service rh-postgresql94-postgresql initdb
service rh-postgresql94-postgresql start