Bug 1315305

Description of problem:
The binaries of applications installed with SCL do not set their RPATH to point to their libraries. I understand that there are good reasons in general to avoid using RPATH when building distribution packages but I feel that software collections are a special case of packaging.

It is usual in Python development to create a virtualenv which creates an isolated environment which runs everything against a specific version of Python. It does this by making a copy of the appropriate Python executable into the virtualenv directory. Ordinarily this is fine since it is copying a system python binary which is linking against system python libraries. However, when using SCLs the python libraries aren't available in the system library search path.

To make it work, as a user you have to enable both the SCL *and* the virtualenv before you can run python. Instead, if /opt/rh/python33/root/usr/bin/python3 sorted an RPATH of '$ORIGIN/../lib64' then the standard Python workflow would work.

How reproducible:
Always

Steps to Reproduce:
$ scl enable python33 -- virtualenv ~/scl_test
$ ~/scl_test/bin/pip list

Actual results:
~/scl_test/bin/pip: error while loading shared libraries: libpython3.3m.so.1.0: cannot open shared object file: No such file or directory

Expected results:
It should run the tool `pip` using the correct SCL version of Python.