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
