On Wed, Oct 16, 2013 at 4:11 PM, Yasha Karant <ykar...@csusb.edu> 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 >> > Various approaches have been tried, and are still in use. RHEL, and thus Scientific Linux, attempt to do this somewhat with Java and SMTP servers by manipulating symlinks using the "update-alternatives" tools, which you might want to look into. For tools that are compiled with numerous multiple versions, outside the RPM infrastructure, Years ago, I got fond of "encap" to keep software form /usr/local/encap[package-version] organized in /usr/local/bin, /usr/local/man, /usr/local/lib, /usr/local/include, etc. It was very effective at symlinking the holw magilla in to /usr/local for you, The approach fell out of favor, but the code is still available at http://www.encap.org/epkg/ > 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). > That's what "mock" is for, which is what Red Hat and Fedora and others use to provide RPM based build environments, with good control over the actual dependencies in the toolchain. > 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 >
