[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: [scl.org] 2 questions on software collections





On 01/06/2016 08:27 AM, Honza Horak wrote:
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.


Yeah, I think we tend to hyper-focus on the python use case, if we were talking ruby or apache it might be better. So, while it may never work for some scls (and I definitely know it is how it wasn't intended to be used) it might be worthwhile to investigate if it works. Even though it kinda flies in the face of "running two versions at the same time."

langdon

Honza

_______________________________________________
SCLorg mailing list
SCLorg redhat com
https://www.redhat.com/mailman/listinfo/sclorg


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]