[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: netcdf packages

Warren Turkal wrote:

> On Thursday 14 December 2006 11:09, Kevin B. McCarty wrote:
>> 1) Why did you make the libnetcdf++3 package into a dummy package and
>> move the C++ bindings into the libnetcdf3 package? ÂIf the soname of the
>> C++ package needs to evolve faster than that of the C/FORTRAN bindings,
>> as I speculated above, this would be a really good reason to keep the
>> C++ bindings in a separate package.
> The netcdf libs are shipped as one tarball.

Sorry, I meant, keep the C++ bindings in the same source package, but
why not put libnetcdf_c++.so.3.6.2 into a different binary package
(libnetcdf++3) as was done before?  If you feel things are better with
all libs in one package, that's OK, I was just curious about the reason.

>> 3) The static libraries (lib*.a) must be shipped in the libnetcdf-dev
>> package, not in the runtime library (libnetcdf3) package. ÂPlease do not
>> ship libtool *.la files at all, as has been requested many times by the
>> release team. ÂSee for instance the discussion at bug #400140.
> This advice seems contrary to [1]. #400140 also seems to contradict [1]. Maybe 
> [1] needs to be updated?

Possibly...  I don't know enough to get involved in that argument,
though.  All I know is that people whose opinion I highly respect seem
to hate .la files ...

>> 4) Your libnetcdf-dev package is missing a Depends line. ÂIt should
>> Depend at least upon the netcdf shared library package(s), upon any
>> *-dev packages that ship files #included by its header files, and upon
>> any *-dev packages that ship static libs depended upon by netcdf static
>> libs. Â(The last is slightly controversial, since there are people who
>> hate static libraries; for that you might be able to use a Recommends
>> instead of Depends.)
> Is there a better way than just listing Depends: libnetcdf3 in the control 
> file for libnetcdf-dev?

Unfortunately not that I am aware of.

> I don't think that it depends on more than the standard lib.

OK.  At least, maybe add a Depends on libc6-dev | libc-dev, and a
Suggests or Recommends (as you think appropriate) on gfortran.

> I have attached the new control file. Can you please check it out?

> Source: netcdf
> Section: science
> Priority: optional
> Maintainer: Warren Turkal <wt@atmos.colostate.edu>
> Build-Depends: cdbs, debhelper (>= 5), autotools-dev, gfortran, texinfo

While I think of it, please add cfortran as a Build-Depends, and in
debian/rules do something to ensure that the build happens using the
copy of cfortran.h in Debian, to ensure consistency.  Probably the
easiest way would be just to

	cp -pf /usr/include/cfortran.h $(CURDIR)/fortran/

in the configure target to overwrite the existing copy.  In debian/rules
clean target, do the following: "rm -f $(CURDIR)/fortran/cfortran.h" in
order to avoid bloating the diff.gz.


> Package: libnetcdf3
> Section: libs
> Architecture: any
> Depends: ${shlibs:Depends}, ${misc:Depends}
> Provides: netcdf, netcdfg, libnetcdf++3
> Conflicts: netcdf3 (<< 3.3.1-1), netcdfg3 (<< 3.6.2), libnetcdf++3 (<< 3.6.2)
> Replaces: netcdf3, netcdfg3

Please also have it replace libnetcdf++3 (<< 3.6.2) if you are going to
have the new libnetcdf++3 be a dummy package.


> Package: libnetcdf-dev
> Section: devel
> Architecture: any
> Depends: libnetcdf3, ${shlibs:Depends}, ${misc:Depends}

${shlibs:Depends} isn't useful for a -dev package, since static libs
(*.a files) don't contain any dependency information that dpkg-shlibdeps
can extract.  As mentioned above, please also add a dependency on
"libc6-dev | libc-dev" and perhaps a Recommends or Suggests on gfortran.

> Conflicts: netcdf-dev, netcdfg-dev (<< 3.6.2)

again, please add the Replaces for these

Rest looks fine.

best regards,

Kevin B. McCarty <kmccarty@princeton.edu>   Physics Department
WWW: http://www.princeton.edu/~kmccarty/    Princeton University
GPG: public key ID 4F83C751                 Princeton, NJ 08544

Reply to: