Re: netcdf packages
On Friday 15 December 2006 16:40, Kevin B. McCarty wrote:
> 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.
I figured that they'd have to be recompiled for each tarball anyway, so I
didn't see a reason to split them since the lib are each only a few hundred K
as most.
> >> 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 ...
I removed the .la files from the next release.
> >> 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 saw some shlibs file in the debian directory of the older package, and
thought maybe I was missing something.
> > 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 suggested it for next release.
However, the refblas3-dev package depends on g77. Does that indicate that I
should depend on gfortran rather than suggest or recommend?
> > 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.
I am researching this one. Would deleting the cfortran.h at the end cause the
diff.gz to be messed up in a subsequent build? Should I copy the version in
the package somewhere else and copy back at the end instead?
> [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.
Done.
> [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.
Removed.
> As mentioned above, please also add a dependency on
> "libc6-dev | libc-dev" and perhaps a Recommends or Suggests on gfortran.
Added Depends on "libc6-dev | libc-dev" and Suggests for gfortran.
> > Conflicts: netcdf-dev, netcdfg-dev (<< 3.6.2)
>
> again, please add the Replaces for these
added
New release (pre4) at [1].
Known issues:
* haven't bumped soname for C++ yet. I want to see if upstream will do that.
* researching cfortran.h issue
* info pages not moved yet, as I am working with upstream on a configure
script issue
wt
[1]http://www.penguintechs.org/~wt/debian/netcdf/
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
Reply to: