Sponsor and review request: opendap, librx

[Ed Hill]

On Sat, 2005-04-23 at 17:31 -0500, Tom 'spot' Callaway wrote:
> 
> New opendap packages (much smaller, much faster to build) which
> incorporate all of Ed's and Michael's suggestions:
> SPEC: http://www.auroralinux.org/people/spot/review/opendap.spec
> SRPM:http://www.auroralinux.org/people/spot/review/opendap-3.4.4-2.src.rpm
> 
> Please sponsor or point out blockers. :)


Hi Tom (& anyone else using FE and scientific/mapping software),

Do you remember me?  ;-)

I realize that its been months since you put time and effort into the
opendap package, but I finally found some free time today to take a hard
look at it.  And found a litany of problems including:

 - opendap-devel pollutes /usr/include with dozens of header 
     files many of which have very generic names

 - some the binaries (eg. Ncview) that it installs immediately 
     seg-fault when run -- they're totally useless

 - it conflicts with a different ncview package that I'd 
     like to separately submit to extras which actually 
     *does* work

 - the opendap-config binary reports nonsense such as:

     [edhill at ernie i386]# /usr/bin/opendap-config --cflags
     -I/home/edhill/rpmbuild/BUILD/opendap-3.4.4/DODS/include

     which shows that its grabbing paths from the build
     location and not the install location  :-(

In my opinion, these problems run much deeper than just packaging.  The
OPeNDAP software (or at least some key components of it) is, in my
experience using it, quite sloppy and amateurish.  For example, I've
seen DODS/OPeNDAP servers gracelessly seg-fault over even trivial
matters such as the totally legal use of certain characters (eg: the
single quote in "Dave's data") within the metadata of netCDF files.

So, why am I bringing all this up?  Well, I'd really like to get NCO
into Fedora Extras:

   https://bugzilla.fedora.us/show_bug.cgi?id=1893

since, even without the optional opendap support, NCO is a *mighty*
useful set of tools for manipulating netCDF and HDF files.  This
includes the default format for many large (eg. atmospheric and
oceanographic) data sets.

So, would it be possible to get NCO into Extras without opendap?  For
instance, would it be OK to declare that NCO, if accepted into Fedora
Extras, could someday support OPeNDAP when/if someone is able to build a
sufficiently clean version of opendap-devel?  Is that a reasonable
solution?

And many thanks for all your help with this!

Ed

-- 
Edward H. Hill III, PhD
office:  MIT Dept. of EAPS;  Rm 54-1424;  77 Massachusetts Ave.
             Cambridge, MA 02139-4307
emails:  eh3 at mit.edu                ed at eh3.com
URLs:    http://web.mit.edu/eh3/    http://eh3.com/
phone:   617-253-0098
fax:     617-253-4464