Sponsor and review request: opendap, librx

[Tom 'spot' Callaway]

On Sat, 2005-06-18 at 20:35 -0400, Ed Hill wrote:

> 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.

There are definitely bugs in their code, there are bugs in all code.
These bugs seem a little bigger than most, but they're not
insurmountable. Please document everything you can find in email to me,
and I'll start spraying RAID on them.

> 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?

I'd say so. If you're willing to help me point out the bugs in opendap
(and maybe squash a few along the way), then I see no reason why we
can't go ahead and get NCO into Extras now.

There's no reason to hold up NCO just because opendap stinks.

~spot
-- 
Tom "spot" Callaway: Red Hat Sales Engineer || GPG Fingerprint: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!