Scott and I first chatted last year about Software Collections when they first became available, and less than a year later he's written up this great summary of his experience with them.
"Red Hat Software Collections
In the beginning
"When I started working at CoverMyMeds, I inherited a server infrastructure that made sense for where the company was at the time. There was one full-time system administrator and a small group of developers. There were only a handful of production servers running a small collection of applications. The majority of applications were Ruby, and Ruby was installed onto the servers using RVM, the Ruby Version Manager.
"We had a number of PHP applications running on different versions of that language, including a custom RPM for a specific version of PHP for one app. The Red Hat default version of PHP was 5.3, which was already ancient by PHP standards."
"This presented me with a few challenges. I wasn’t keen to maintain a custom RPM for PHP, nor was I eager to roll my own RPMs for our Ruby versions. Tracking CVEs and release announcements for Ruby and PHP was not something I could practically do and still be successful at all of the other requirements of my job. Third party binary RPMs weren’t much of a better choice, either, since I’d still have to verify the packages in some meaningful way.
"What I really wanted was for Red Hat to distribute updated versions of Ruby and PHP, amongst other things.
A better way
"At Red Hat Summit 2014 I learned about Red Hat Software Collections and immediately became excited. Here was an opportunity to access new versions of the interpreted languages on which our developers relied, delivered by Red Hat in RPM format, trackable by Red Hat Satellite!
"As with any technology, Software Collections is not a silver bullet."
Read Scott's whole article here: Red Hat Software Collections – ScriptScribe.
Last updated: March 14, 2024