1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 <2016> 2017 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 <2016> 2017 2018 2019 2020 2021 2022 2023 2024 |
<== Date ==> | <== Thread ==> |
---|
Subject: | Re: Philosophy regarding use of open source libraries for EPICS |
From: | "Shen, Guobao" <[email protected]> |
To: | "Konrad, Martin" <[email protected]>, Bruce Hill <[email protected]>, "[email protected]" <[email protected]> |
Date: | Wed, 16 Nov 2016 21:01:19 -0500 |
Hi Bruce, As Martin said, our strategy is to update our OS when there is new release. More specifically, we have our evaluation in our test bed for a period, about half year for example, then migrate our production deployment if there is no problem found. NSLS II has created lots of packages for Debian 7, and we here at FRIB update them to Debian 8 (latest stable version). We are looking for collaboration on this if there is any interest. Thanks, Guobao On 11/16/16 6:59 PM, Konrad, Martin wrote:
Hi Bruce,Relying on yum repo installation of third party packages wasn't working as the available package versions were often way out of date.I guess that's the price you pay for sticking to the same RHEL version for 10 years ;-) We are planning to upgrade our OS more frequently (whenever a new Debian version is released).To handle this, we created a python based system we call package manager. It consists of python scripts that know how to build and install typical c/c++ unix packages from tarballs using ./configure, make, make install, and also how to build and install python packages using setup.py build and setup.py install. For each package type, there's also a dependency file to specify version specific package dependencies, and a short python file to handle quirks of each package type. For an easy package the new python code is about 10 lines of boilerplate, but we've also handled builds which use qmake, autogen, cmake, etc. We can also customize configure arguments, build arguments, add missing headers, customize installs etc.If you go through all that pain you can also package your software into RPMs. We are building Debian packages for almost everything. The nice thing about this is that we can leverage the Debian community's big pool of packaging/build tools. Have a look at [1] for an example of the kind of meta data we add to turn something into a proper Debian package. [2] is an example for the build rules that are automatically generated by the Debian tools (we usually don't need to touch them). The best thing about all this that the packaging effort for a lot of common packages is shared between labs [3]. -Martin [1] https://github.com/epicsdeb/ether-ip/blob/master/debian/control [2] https://github.com/epicsdeb/ether-ip/blob/master/debian/rules [3] https://github.com/epicsdeb