[scl.org] 2 questions on software collections

Honza Horak hhorak at redhat.com
Wed Jan 6 13:27:16 UTC 2016


On 01/05/2016 05:22 PM, Langdon White wrote:
>
>
> On 01/05/2016 11:00 AM, Jim Perrin wrote:
>>
>> On 01/04/2016 02:22 PM, Langdon White wrote:
>>
>>>> 2nd: how do I switch permanently to the version of the sotfware
>>>> collection for a user? If I run
>>>>
>>>> $ scl enable rh-perl520 bash
>>>> after logging off and on I get back to system perl version. Adding
>>>> that line to ~/.bash_profile seems to do the trick. Is this the
>>>> correct way to do it?
>>>>
>>> I wrote a quick blog post about this some time back. I think this is
>>> still something we would like to see a better solution(s) for.
>>>
>>> http://developerblog.redhat.com/2014/03/19/permanently-enable-a-software-collection/
>>>
>>>
>>
>> It would be interesting to see if it's possible to easily expand the
>> scope of the alternatives framework to include scls. This way admins
>> could take what they already use for java and use it to manage scl
>> version choices as well.
>>
>
> Yeah.. I have thought about that a bunch too.. but haven't had a chance
> to look at it...
>
> I know some people have had success with mucking about using environment
> modules (IIRC the name), ncoghlan comes to mind....

Environment modules is the implementation behind the newer scl-utils 2.0 
(available just in Fedora, not RHEL yet). With that, something like this 
should be possible to do:

    module initadd <sclname>

The `alternatives` is not something I'd recommend, because that is based 
on creating system-wide symlinks. So, e.g. creating /usr/bin/python that 
would be actually python SCL binary (or wrapper) is not a good thing to 
do. That is not how SCLs were designed to be used. SCLs were designed to 
be used only when someone asks for `python`, but /usr/bin/python should 
always point to system python.

Honza




More information about the SCLorg mailing list