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

-- 
James Fait, Ph.D
Beamline Scientist
SER-CAT, APS
Argonne National Laboratory
Building 436B-008
9700 S. Cass Ave.
Argonne, IL 60439

Email: [log in to unmask]
Phone: 630-252-0644
Fax:   630-252-0652


----- Original Message -----
| From: "Yasha Karant" <[log in to unmask]>
| To: [log in to unmask]
| Sent: Wednesday, October 16, 2013 10:30:28 AM
| Subject: Re: blue griffon current production successfully built
| 
| On 10/16/2013 03:46 AM, Nico Kadel-Garcia wrote:
| > On Tue, Oct 15, 2013 at 2:03 PM, Yasha Karant <[log in to unmask]
| > <mailto:[log in to unmask]>> wrote:
| >
| >      From a terminal application within gnome, my default Python
| >      is:
| >
| >     [ykarant@jb344 ~]$ python
| >     Python 2.6.6 (r266:84292, Feb 21 2013, 19:26:11)
| >     [GCC 4.4.7 20120313 (Red Hat 4.4.7-3)] on linux2
| >     Type "help", "copyright", "credits" or "license" for more
| >     information.
| >      >>>
| >
| >     despite having to install whatever the BlueGriffon build
| >     required.
| >
| >     A number of the responses concerning the build of BlueGriffon
| >     further underscore the general lack of polymorphism and
| >     encapsulation in the Linux environment as distributed.  In a
| >     proper
| >     modern OS environment, an application that requires non-system
| >     versions of applications (other than the core libraries
| >     required by
| >     the OS itself, a more daunting problem) would have only these
| >     in the
| >     path of both the building steps and during the execution of the
| >     built application, preferably still allowing a dynamic rather
| >     than a
| >     static image of the built application.
| >
| > You've gone on about this before, and it's just not going to happen
| > with
| > this OS. SL is a rebuild of a server class operating system, not a
| > maximal flexibility operating system. The trade-off is that there
| > is a
| > hope for stability and interoperability and consistent behavior
| > from day
| > to day, due to the consistent library versions, package layouts,
| > and
| > build environments. And such a multi-component, multi featured
| > system is
| > vulnerable to serious incompatiblities between even minor library
| > or
| > feature changes. Python 2.6 and Python 2.7, for example, have
| > notable
| > feature and syntax differences. So at run-time of particular Python
| > modules, which is the default to select? Do all python scripts have
| > to
| > be written as "/usr/bin/python2.6" or "/usr/bin/python2.7"? And how
| > is a
| > tool author writing their Makefile or configure.ac
| > <http://configure.ac>
| > to know? Or even just running a remote shell script.
| >
| > Do not get me *started* on software tools that auto-update your
| > local
| > workspace databases to enable new features and make it impossible
| > to
| > revert back to the older binaries, such as Subversion and RPM.
| > running
| > both versions on the same system at the same time is *fraught* with
| > adventure.
| >
| > This is just not a "Linux" problem. It's a "consistent environment"
| > problem. there have been attempts to deal with the need for
| > multiple
| > versions of components at the same time with the /usr/bin/Java and
| > /usr/bin/gcc symlink fun and games, but it's an unavoidable
| > problem,
| > especially in a system for which the paying customers need a
| > consistent
| > environment and a 10 year life cycle (which our favorite upstream
| > vendor
| > currently provides.)
| >
| 
| You may oppose modern software engineering design and implementation
| principles and practices.  I have never proposed a lack of stability
| or
| reliability in any environment, whether that environment is an
| operating
| system or an end-user application specific to only one segment of the
| population.
| 
| Indeed, the designed language or environment that is required by a
| build
| should be specified in the build.  If Application N.m is required, it
| should be specified.
| 
| As you factually point out, a number of the core applications (such
| as
| RPM or other production maintenance utilities) routinely are updated
| by
| TUV and even by the community (other software application
| maintainers,
| both for-profit and commons) and then auto-update, and do not
| necessarily maintain backward compatibility.
| 
| In some cases, there is no choice due to either an algorithmic
| shortcoming or a fundamental implementation shortcoming, typically
| one
| that results in the possibility of a major security compromise on a
| network-attached node ("hack" or "attack" vulnerability to exploit).
|  In
| most cases, however, the cause merely is new capabilities or
| features,
| or a change in the underlying standard due to newer technologies and
| loss of other technologies from the wild.
| 
| One can have a stable environment with polymorphism and
| encapsulation,
| but this is not easy, particularly for heritage implementations.
| 
| Yasha Karant
|