> > > > That's the very problem that Software Collections endeavors to solve. If > > you install a non-standard package that conflicts with OS defaults, > > install it as a collection so that end users can choose whether to use > > the enhancement or the default, on a per-session basis. > > Does that mean you end up needing to manage crazy long PATH variables? Manage in what way? The SCL can be used in a number of ways. Most people do it by invoking a shell preconfigured with the correct environment by doing something like scl enable devtoolset-3 bash exiting out of the shell obviously restores your original environment. You can start programs other than a shell in the same way. There is also the option of running the collection's enable script to set up the environment in the current shell. e.g. /opt/rh/devtoolset-3/enable but there is no easy of removing the environment other than restarting the shell. There's information on the RH website about software collections and how to package things properly and how to convert spec files etc. etc. P. _______________________________________________ CentOS mailing list CentOS@xxxxxxxxxx https://lists.centos.org/mailman/listinfo/centos