Software Collections on Red Hat Enterprise Linux

-1+1 (No Ratings Yet)

Did you ever wish you had newer versions of the software on your Red Hat Enterprise Linux machines? You are probably not alone. Providing new versions of software in rpm is hard, because rpm supports only one version installed on your computer at a time. Multiple versions on one machine can conflict with each other or create unpredictable behaviour in applications that you might not have considered dependencies.

Last year, we developed Software Collections to allow you to install newer versions of software in rpm safely into /opt and switch between new and old releases. This allows your Red Hat Enterprise Linux system applications to continue to run with the old version, while new apps can work with the new version. A good example of this is Python; many essential packages are written in Python. How can you update to the latest release of Python without causing half your system to break? Through Software Collections, you can install a newer version of Python – for example python-3.3 – into /opt avoiding conflicts in files and strange behaviour of apps that depend on an older version of Python.

I have multiple collections on my RHEL-6 machine for testing purposes. Let’s see all of them:

[root@rhel-6-marcela ~]# scl -l

How can you install those collections?
These collections are located as testing repositories on various “people pages.” You can add their repository into your /etc/yum.repos.d/:

cd /etc/yum.repos.d/

For Ruby 1.9.3 with Rails run:


Install the whole collection by:

yum install ruby193

You can do the same for Python-3.3 or Python-2.7, PHP-5.4, and databases (postgresql,mysql). Updated links and documentation are on the home page of Software Collections. It’s possible to execute a single command with the collection version of the software. As a Perl programmer, I will show you Perl. Let’s look if the collection version is really going to be used:

[root@rhel-6-marcela ~]# scl enable perl514 'perl -V'
Summary of my perl5 (revision 5 version 14 subversion 2) configuration:

I can enable the collection of new software in one shell session and work with it there:

[root@rhel-6-marcela ~]# scl enable perl514 bash

Now, I can use the features of perl-5.14. However, this does not get us the modules or gems for your preferred language. Modules (or gems) installed into standard paths like /usr/lib won’t be used, because they are built with an older version. All prepared collections contain some basic modules, but not everything can be packaged. Users will have to install the rest of the modules by the normal package tool (cpan, rubygem, easy_install, …) or create their own rpms.

Let’s install the pip module for Python by using easy_install:

[root@rhel-6-marcela ~]# scl enable python32 bash
[root@rhel-6-marcela ~]# easy_install pip
Searching for pip
Installed /opt/rh/python32/root/usr/lib/python3.2/site-packages/pip-1.2.1-py3.2.egg
Processing dependencies for pip
Finished processing dependencies for pip

Check whether the module is installed into collections file space:

[root@rhel-6-marcela ~]# which pip

Why would you want multiple versions on one system?

Some use Software Collections to develop applications using new releases of their favourite software on a current, stable Red Hat Enterprise Linux system. Others use them to port their apps from an old release to the latest version to take advantage of new features (for example, new features are being added to Rails frequently).

There are also developers who want to port their applications first on a prehistoric system like RHL-8 and then move to something like RHEL-5 or  RHEL-6. For example THEY port their apps written in perl-5.8.0 to perl-5.16.2 and then move their app to a newer system. The Perl collection will be the same on both systems, so it can work on both systems and benefit from an improved operating system.

You could also have the same application running on the same release of software on multiple Red Hat Enterprise Linux releases. It’s even possible to package older versions of the software, though we expect this will be a limited use case.

Software Collections provides you with the flexibility to run multiple versions of apps on the same instance of Red Hat Enterprise Linux. This allows you to retain the production stability of Red Hat Enterprise Linux while you adopt newer innovations as part of your development efforts.

What did you think of this article?
-1+1 (No Ratings Yet)

  1. After running $ scl enable python27 bash, for example, python27 is run, but easy_install still acts upon default python26. What pathing changes must I make?

    1. This is kind of a tough one. If you have done an “scl enable” easy_install should be working correctly. However, sometimes, especially if you are using sudo, some of the context gets messed up because of sudo environment switching. I would recommend actually su’ing to root and running “scl enable” there or, take a look at this post: and see what I do for easy_install and pip.

  2. Can the installation location of software collection be changed ? How to do that ? For eg., in centos I would like python2.7 to be installed in /usr/local instead of /opt/rh ?

    1. Usually we modified initscripts to run properly. They are installed into /etc/init.d/ directory, but they contain different paths to content of collection. I’ll write about initscripts and unit files posts later this week.

  3. Software Collections is a great way to maintain more current versions of software on RHEL. Case in point, RHEL 7 ships with 5.4.16, but PHP 5.4 “officially” EOL Sept 2015 (which, yes, I know RH will support with security patches… but not functionality!)… And we won’t even see RHEL 8 for another 2 years minimum??

    HOWEVER, we run RHEL on pSeries, which last time I looked wasn’t supported at all (or even built). Does anyone know if software collections will EVER be available for ppc_64!? One would hope so, given the above state for PHP and all apps built with it…

      1. Thanks Mike. I’m jaded enough to assume one (or a few) voices might not get them to actually do it, but I will put in the effort.

        I also joined an SCL list, and a couple people say as COPR progresses, there’s a path there to take the source rpms (e.g. from intel) and easily have COPR rebuild for whatever platform you wish; And once someone has done that for the platform (ppc64/epel in this case) and submitted it to SCL’s repo (or epel), you wouldn’t even need to build with COPR yourself. So there might be a couple options, potentially.

        Thanks again!

Leave a Reply