Red Hat Bugzilla – Bug 167111
Review Request: libdap and libnc-dap the OPeNDAP libraries 3.5.2
Last modified: 2010-07-19 23:09:03 EDT
This is a review request for libdap and libnc-dap although these are distinct packages.
The libdap++ library contains an implementation of DAP2. This package
contains the library, dap-config, getdap and deflate. The script dap-config
simplifies using the library in other projects. The getdap utility is a
simple command-line tool to read from DAP2 servers. It is built using the
library and demonstrates simple uses of it. The deflate utility is used by
the library when it returns compressed responses.
The libnc-dap library is a call-for-call replacement for netcdf 3.5 (and
is mostly compatible with netcdf 3.6). It can read and write to and from
netcdf files on the local machine and it can read from DAP2 compatible data
servers running on local or remote machines. Data served using DAP2 need
not be stored in netcdf files to be read using this replacement library.
Also included in this package is the ncdump utility, also bundled with the
original netcdf library, relinked with the library and thus able to read
from DAP2 compatible servers.
There is allready opendap-3.4.4 in fedora cvs (with the servers ?). The servers
are not released for 3.5.2. As libdap in opendap-3.4.4 and libdap in 3.5.2 are
incompatible as stated on the opendap site (although I don't know how...), maybe
it would be nice to have both. I have tested that opendap-3.4.4 and libdap-3.5.2
and the devel packages can coexist, as the names of libraries and utilities
changed between the releases.
libnc-dap-3.5.2 and opendap-3.4.4 conflict, however. I think that this is not a
problem as they are compatible (as much as the netcdf interfaces are
compatible). So maybe a good thing would be to split opendap-3.4.4 in
opendap-libdap and opendap-nc-dap (or opendap-ncdods as it is called like that
in this release if I'm not wrong) such that the libdap pars can be installed
along while the libnc-dap conflict.
Myabe it would also be a good idea for the various subpackages of opendap to
provide the new names, say libnc-dap-devel (with version 3.4.4). And if you
think it is a good idea libdap-3.5.2 and libncdap-3.5.2 could provide the old
rpmlint complains about the licence for libdap, however there is really a file
under the W3C licence so I think it is right.
W: libdap-devel invalid-license LGPL/W3C
Hi Patrice, thanks for submitting this--its good to see someone volunteering
to work on it! I'm very busy right now and won't get a chance to look at it
for a few days. If Tom (who maintains the opendap package) or someone else
doesn't sign on as the reviewer for this, then I'll do so next week.
Hi Patrice, sorry for the delay. I've looked at your libdap-3.5.2-3.src.rpm
package and have the following comments:
+ RPM builds in FC-4 mock
+ no rpmlint errors
+ source matches upstream
+ specfile looks good (readable, code not content, etc.)
- the Source0: URL is either out-of-date or wrong, please use:
- upstream is now at 3.5.3 but its your decision whether to update it
Moving on to potential conflicts with the opendap* packages, I don't know
what to say. I haven't checked to see if there are any conflicts. And
even if there are, I don't know if it even matters for FC-4+ since the
opendap packages aren't available due to serious build problems on 64-bit
So, how about we proceed by saying that libdap-3.5.2-3.src.rpm is APPROVED
for FC-4+ and that a separate bugzilla entry should be opened for the
libnc-dap-3.5.2-4.src.rpm package. That will give a reviewer (probably
me) a chance to test-build the latter in mock following inclusion of the
former into the Extras repository.
Here is an updated srpm with the correct Source0, updated to 3.5.3
Once it is approved I'll resubmit libnc-dap in a separated bugzilla entry.
Looks good -- libdap-3.5.3-2.src.rpm is APPROVED.
Package Change Request
Package Name: libdap
New Branches: EL-6
CVS done (by process-cvs-requests.py).