On Wed, 16 Oct 2013, Jeffrey Anderson wrote:
--089e013d0db08caeb504e8e18c7a
Content-Type: text/plain; charset="ISO-8859-1"
It seems to me that the "environment-modules" package available from EPEL
can address many of your needs.
We use it to provide access to multiple versions of python, gcc, boost, gsl
and many other tools and libraries, all without interfering with necessary
system-level operations. It is quite flexible, has a relatively low
learning curve, and is widely used. It allows users to easily switch back
and forth between different versions of these tools.
Need python 2.7.2?
'module load python/2.7.2'
Want to switch to 2.6.4?
'module switch python/2.6.4'
Want to go back to the default system python?
'module unload python'
and so on.
Jeff
TUV and thus SL has had the technology known as "Software Collections"
available in SL6 since 6.2 .
Software Collections installs packages in /opt/rh and thus preserves the base
packages. It provides a utility , scl , to "enable" these software
collections.
TUV and thus SL has released "Devtoolset" which provides newer GCC via
"Software Collections".
Recently TUV and thus SL released "Software Collections" (uses scl but more
than that) that provides
mariadb55
postgresql92
ruby193
mysql55
python27
nodejs010
python33
perl516
php54
A README with info about yum repos for these packages is available from
ftp://sldist.fnal.gov/linux/scientific/6x/external_products/softwarecollections/README
More info from TUV is available at
https://access.redhat.com/site/documentation/Red_Hat_Software_Collections/
Note that Oleg responded to this thread with this info a few days ago.
The Software Collection python27 solves this problem completely.
-Connie Sieh
>
On Wed, Oct 16, 2013 at 1:11 PM, Yasha Karant <[email protected]> wrote:
On 10/16/2013 09:12 AM, Jim Fait wrote:
I run into this all the time, as we have a large number of somewhat
incompatible software packages that we are required to have. What we have
ended up doing is placing the real executable somewhere outside the normal
path, and then putting a script with same name in /usr/local/bin or
/opt/local/bin that encapsulates all of the foreign dependencies and
environment. That way, the particular package can live with its
requirements alongside the production system, with very few problems seen
by the end user.
Of course, this means writing a number of scripts, in our case a couple
hundred, that stay fairly static with changes in the OS or the package in
question, and that hide all of the nastiness that otherwise would happen,
like a PATH environment variable 10 line long.
Hope this idea helps.
Jim
Your example is one of the accepted methods for enabling the idea of
polymorphism and encapsulation within an otherwise procedural imperative,
possibly structured, environment. Assuming that what you are describing is
for both the build environment and the execution environment of the
environment/application being built, it should (in most cases) work. And
-- it should be the norm when providing application building environments
that do NOT require a virtual machine (e.g., maintaining a "more modern"
Linux under VirtualBox under SL6x).
I do not know which applications/environments you support in this way. A
list of all that are not subject to for-fee or equivalent non-distributable
licenses and for which you are willing to provide the scripts greatly would
be appreciated. Maintaining such environments across new major OS
environment releases often entails a large amount of effort.
Yasha
