Red Hat Software Collections can make your life as a programmer or admin immensely easier.
Like death, taxes and zombies, dealing with different versions of software is something you just can't avoid. It's a nasty but necessary fact of life.
Traditionally, when developers and system admins grapple with this issue, they have to sacrifice something. If you want to run the latest and greatest version of a web app, it might not support users with outdated browsers. If you install the newest beta release of Python so you can test development code, it might break Python scripts written for older releases. If you have a system with multiple users, you might want a different version of Ruby over another. And so on.
Software Collections provide a solution to conundrums like these. They let you have your cake and eat it, too.
In other (more technical) words, Software Collections make it possible to have multiple versions of the same software on the same system. You use a simple tool to tell the system which version to activate as needed.
If that sounds awesome, it is. Keep reading for a more detailed explanation of how Software Collections work, and an overview of using them on your Red Hat system.
Software Collections: What They're Not
If you are currently thinking that Software Collections sound too good to be true, you might be assuming they just use virtualization or containers to have multiple versions of the same software running on the same system. Anybody could install different versions of a program inside a virtual machine atop the same host, of course. That's not a big deal.
Software Collections don't rely on virtualization, or entail any of the resource or administrative overhead of hypervisors. They keep things lean and mean, yet provide a level of version flexibility that you would otherwise only be able to get through virtualization.
You might also be wondering whether Software Collections are just a weird hack that lets you install multiple versions of the same package. Technically, you could do something like this (and maybe you already do if you need multiple versions of Python or PHP on the system, for instance) by modifying installation scripts and system directories in strange ways to accommodate multiple releases of the same binaries. But Software Collections don't require that kind of dirty work.
Software Collections also won’t break yum or dnf. They're designed to play nicely with the package manager and prevent conflicts between packages.
Software Collections: What They Are
So what actually makes Software Collections tick?
Essentially, they're special RPM packages that can be installed on the system and activated as needed using a special interface. With this approach, they don't conflict with or overwrite software installed by any other RPM packages that are designed to run normally.
You can build Software Collection RPMs yourself either locally or via COPR. This makes them a handy way of distributing apps to users who want to be able to switch between different versions of your software easily. It also simplifies the process of running multiple versions of the same app on your own systems for testing purposes.
Using Software Collections
If you just want to use Software Collections, though, you don't have to know much about building packages. You just need to enable the Software Collections repositories on your system, then download, install and activate whichever packages you want.
To complete the first step on RHEL, run the </span><span style="font-weight:400;">subscription-manager-gui tool and use it to enable the </span><span style="font-weight:400;">rhel-server-rhscl-7-rpms and </span><span style="font-weight:400;">rhel-7-server-optional-rpms repositories. (If you don't see these repositories listed, they're likely not included in your RHEL subscription.)
You could also do that from the CLI with:
# subscription-manager repos --enable rhel-server-rhscl-7-rpms
After this, you simply use yum to install whichever Software Collections package you wish from the repositories you enabled. For example, to install the package for MongoDB 2.6 (called rh-mongodb26), run:
# yum install rh-mongodb26
Lastly, you use the tool scl to activate your new package. For example, this command would activate the rh-mongodb26 package to run in a Bash terminal:
# scl enable rh-mongodb26 bash
That's all there is to it. Now, you can run the MongoDB 2.6 software you installed in a terminal just as you would a normal application, using a command like:
# service rh-mongodb26-mongod start
Of course, none of this will impact any other version of MongoDB that you have installed on your system. And that's the real beauty.
Further Reading
For all of the details on using Software Collections, you can check out the RHSCL documentation online. The RHSCL 2.2 Release Notes have a list of the collections available from Red Hat.
One last tip: If you're wondering how to make Software Collections persist through reboots, here's your answer.
Featured image source: harmonycentral.com
About Hemant Jain
Hemant Jain is the founder and owner of Rapidera Technologies, a full service software development shop. He and his team focus a lot on modern software delivery techniques and tools. Prior to Rapidera he managed large scale enterprise development projects at Autodesk and Deloitte.
Last updated: March 16, 2023Editor's Note: developers.redhat.com has get started guides for Software Collections that take you up to "Hello, World" and answer some of the frequently asked questions.