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 <[EMAIL PROTECTED]>
> 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.
[snip]
> 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.
[snip]
> 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 <[EMAIL PROTECTED]> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
