SCL Packaging Bugaboos

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

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
  Copy Copied!

  bundle

  and find that
  Copy Copied!

  bundle

  is not in the PATH-elements that are activated by the
  Copy Copied!

  /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

• Get ruby to create my baseline RedMine config and gems.
• Create my
  Copy Copied!

  Passenger.conf

  and verify it's good
• Start
  Copy Copied!

  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
  Copy Copied!

  /etc/ld.so.conf.d/

  and run
  Copy Copied!

  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/

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