EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Philosophy regarding use of open source libraries for EPICS
From: "J. Lewis Muir" <[email protected]>
To: Rod Nussbaumer <[email protected]>
Cc: epics Techtalk <[email protected]>
Date: Wed, 16 Nov 2016 10:52:45 -0600
On 11/16, Rod Nussbaumer wrote:
> All:
> 
> I would like to get peoples' opinions about the right way to deal
> with open source third party libraries that get bound to EPICS
> applications, particularly on Linux, but wherever else it comes into
> play. An example case would be libgif, which can be used by EDM to
> display GIF images in EDM screens. The Area Detector package seems
> to make significant use of such libraries for image processing. So
> far, the standard procedure here has been to install the libraries
> from binary repositories supported by OS vendors such as Redhat,
> Debian, etc. We do this on development hosts and the matching
> production host architectures. However, this leaves us vulnerable to
> incompatible changes that may be introduced due to routine
> maintenance of the hosts, and silently changes the deployed EPICS
> software with no knowledge of the effect, or testing that it works
> as expected. The alternative would be to build from sources, all
> libraries that go into an EPICS application, and install the lib
> binaries in a way that they get used in lieue of the
> system-installed packages. Does anyone do that? Am I being paranoid?
> The obvious question is how far would you take this approach, since
> literally everything binds to libc, libm, and some other standard
> libraries.
> Thanks in advance for your opinions.

Hi, Rod!

My opinion is that the more that can be provided by the OS, the better.
When you provide the library yourself, you're taking on responsibility
for maintaining it (e.g., bug fixes).  You have to subscribe to a
mailing list for each library or somehow ensure you become aware of
important fixes.  Then you have to understand the fix and apply a patch
for it or upgrade the library to a new version (if you can do so without
breaking other libraries you're including that depend on it).  And
finally you have to deploy a new version of your software that includes
the fixed library any time any library needs fixing.  When the OS
provides the library, you don't have to worry about any of that.

As far as stability goes with libraries changing under you, the whole
point of the versioning scheme of shared libraries is to enable your
software to continue working correctly and not need to be recompiled.
If you're on an OS that is supported for a long time (e.g., RHEL, Ubuntu
LTS, etc.), you should be fine.

Regards,

Lewis

References:
Philosophy regarding use of open source libraries for EPICS Rod Nussbaumer

Navigate by Date:
Prev: Re: Philosophy regarding use of open source libraries for EPICS Konrad, Martin
Next: RE: OS X edm/medm openmotif woes Mark Rivers
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Philosophy regarding use of open source libraries for EPICS Siniša Veseli
Next: Re: Philosophy regarding use of open source libraries for EPICS Bruce Hill
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Nov 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·