[gembud] GEMPAK binary builds and revision control

Hi Daryl-

Thanks for your comments about binary builds. I'll try to clarify Unidata's position on this.
When Unidata released GEMPAK 5.11.1 in December 2007, we produced binary 
builds.  The majority of the support questions after that release were 
related to incompatibilities of the binaries with the system libraries. 
Sometimes, tracking down these issues was very time consuming. In most 
cases, building GEMPAK from source solved the issues related to binary 
builds.
After discussions with the Unidata User's Committee and Policy 
Committees, the UPC decided that providing source only distributions in 
the future was warranted because:
- As operating systems move forward, the binary builds will likely 
become incompatible with newer libraries.
- The UPC does not have access to the wide range of systems that are 
currently being used in the GEMPAK community.
- The UPC does not have the resources to continually produce binary 
releases with each source change.
Both committees endorsed this action.

The source only distributions have been a (re)learning experience for the users and the UPC. While on the one hand, the scope of the support questions has changed, the problems are usually very similiar - incompatible or missing libraries. GEMPAK 5.11.4 was a major change in the structure of the GEMPAK source tree, and it has caused some build problems on our end. Fortunately, the gembud community has helped us address these. We appreciate those of you in the gembud community who are willing to provide help to the UPC and others.
As we move forward, the following actions are being taken:

- a discussion of GEMPAK support will be held during the upcoming User's Committee meeting (March 11-12, 2010).
- We will be beefing up the GEMPAK build documentation to include more 
information about frequently encountered problems as well as solutions 
and/or workarounds.
- We have contacted NCEP about providing access to the source code in a 
repository fashion.  Currently, Unidata does not have the rights to 
distribute the software in this fashion.  NCEP requires us to have users 
register to download the software.  If we are able to set up a 
repository access, we will be looking for some experienced community 
members to vet any changes before they are committed to the repository.
- We could set up an area in our downloads section where site 
contributed binaries would be accessible.  Several sites have provided 
precompiled binaries for compatible systems that we don't have access 
to.  These would be provided on an "as is" basis.
As the migration to AWIPS II progresses, we expect the gembud community 
to take a more active role in support of the legacy GEMPAK code. Unidata 
plans to support the last version of the current GEMPAK/NAWIPS software 
for 18 months after the first official release of AWIPS II by NCEP to 
the National Centers and to the Unidata community. The GEMPAK source 
code will still be accessible in some form after the UPC ends official 
support. It will not stop working on any certain date. Furthermore, the 
existing support materials (tutorial, help manual and documentation) 
will still be available on line. The gembud mailing list will be kept 
active so GEMPAK users can provide community support to each other.
Please see the NAWIPS Migration Information at:

http://www.unidata.ucar.edu/software/gempak/nawipsmigration/

for additional information on GEMPAK and AWIPS II.




On 02/18/2010 08:33 AM, daryl herzmann wrote:
Hello Jason,

I wish Unidata would state a reason why they no longer produce GEMPAK binaries, but regardless, we are left with all this compiling fun. Looking at your Centos Errors, netcdf is not building for reasons I have yet to figure out (appears it requires a lot of tetex stuff to build docs). I ended up hacking in netcdf 4.1 to help it to build cleaner with gfortran.
<personal rant>
I sure wish Unidata would support public source code trees and revision systems of GEMPAK, so the community could actively help develop it. Unfortunately, Unidata doesn't develop code in an open manner. We have to wait for it to "come from on high", a.k.a the 13th floor of the Unidata tower, hehe!
</personal rant>

Anyway, I know others on this list are producing RPMs, so hopefully they'll have something to share with you. My RPM foo is not strong enough to provide binaries for RHEL and RHEL clones yet.
I ended up installing: tetex-dvips , openmotif-devel, texinfo, tetex  
and got it to work, I think.
daryl



  • 2010 messages navigation, sorted by:
    1. Thread
    2. Subject
    3. Author
    4. Date
    5. ↑ Table Of Contents
  • Search the gembud archives: