SCL Packaging Bugaboos

Latest response

So, I've got an application (RedMine) that wants a newer version of Ruby (2.2+) than is stock with RHEL 7. Silly me figured, "lets see what if SCL can help me." I do a quick search and see that there's rh-ruby22, rh-ruby23 and rh-ruby24.

"Dandy," I think to myself. This was before I started going down the rabbit hole of actually trying to make the SCL packaged version usable.

  • Created an /etc/profile.d/enable_rh-ruby2.sh script with:
#!/bin/bash
source /opt/rh/rh-ruby24/enable
export X_SCLS="$(scl enable rh-ruby24 'echo $X_SCLS')"

in it.

  • Go to run bundle and find that bundle is not in the PATH-elements that are activated by the /opt/rh/rh-ruby24/enable script. Have to update my profile.d script to add
export PATH=${PATH}:/opt/rh/rh-ruby24/root/usr/local/bin

so that bundle will work

  • Get ruby to create my baseline RedMine config and gems.
  • Create my Passenger.conf and verify it's good
  • Start httpd (no errors, yay!)
  • Browse to my URL and get an error - check my logs and find that the SCL-packaged Ruby was unable to find its libs because they're dynamically-linked and not in the default lib search path.
  • Create an appropriate file in /etc/ld.so.conf.d/ and run ldconfig. The SCL-packaged Ruby is now able to find its libs.

This isn't the only time that I or peers have run into issues with SCL-packaged software. Most have taken to either using offerings from other repos than trying to fight the SCL peculiarities. For whatever reason, I'm a bit more bloody-minded (not wanting to be defeated by software, I guess). The SCL struggles feel a lot like dealing with the early days of SunFreeware (Solaris) packagings ...or the even earlier days of Solaris when everything went into /opt/<PACKAGE>.

Am I missing something about the value of SCL packagings or do the SCL packagings need improvement?

Thomas Jones's picture

Responses