Here is more info from Kevin from debian-mentors. I have asked if he could
temporarily join this list and this discussion about what to do with the
soname on the libs.
---------- Forwarded Message ----------
Subject: Re: netcdf packages
Date: Monday 18 December 2006 12:36
From: "Kevin B. McCarty" <kmccarty@xxxxxxxxxxxxx>
To: debian-mentors@xxxxxxxxxxxxxxxx
Warren Turkal wrote:
> On Friday 15 December 2006 17:22, Warren Turkal wrote:
>> Known issues:
>> * haven't bumped soname for C++ yet. I want to see if upstream will do
>> that.
>
> Ed from upstream had a question:
>
> ***
> I'm not too strong yet on how these numbers are used, but last time I
> looked into it the conclusion was to release version 3.6.2 of netCDF
> with:
>
> -version-info 0:0:0
>
> Any comments would be welcome. Do you think this is correct?
> ***
I'm not clear exactly how libtool translates -version-info flags to
version numbers. (If I read the libtool script right, then
-version-info X:Y:Z translates to "libfoo.so.(X-Z).Z.Y" on Linux.)
However, it is definitely the case that having -version-info 0:0:0 will
create a library with filename "libwhatever.so.0.0.0" and soname
"libwhatever.so.0". This will break any binary compatibility with
previous netcdf versions, so it would definitely become necessary to
rebuild existing programs against the new netcdf. (This is always a
risk when a Debian packager hacks in shared library support, and then
later upstream decides to support building shared libraries in the
official source.)
If upstream is sketchy about library versioning, please ask them to read
the "Library interface versions" chapter of the libtool Info docs, and
hopefully all will become clear :-) Maybe also point them at the C++
ABI FAQ mentioned in a previous email of mine:
http://www.trolltech.com/developer/knowledgebase/362/
> Can you please comment on this issue as to what would help us ship a
> non-modified upstream soname?
If upstream were to ship netcdf 3.6.2 using -version-info 4:0:0, that
would put their soversion higher than any that had previously been
hacked in by downstream suppliers. So you might ask them if they could
do that. (Again this would necessitate rebuild of netcdf-depending
programs. But my best guess is that ABI compatibility from netcdf
version 3.6.1 has already been broken, based on your description of the
situations in which kst-plugins had a segfault. At least having
upstream start with libnetcdf.so.4 would guarantee a monotonic
progression of soversions in the Debian package history.) Of course,
it's up to them whether they are willing to do so. If they don't,
Debian will have to support whatever their official decision is.
>> * researching cfortran.h issue
>
> I have asked upstream to prefer the system version of cfortran.h over the
> one included in the tarball.
I saw your copy of their response, which was basically "we always want
to prefer our own version in case the system version is old and buggy".
As far as I can tell, though, netcdf changes to cfortran.h 4.3 are
pretty minimal, and consist mainly of adding cygwin, Pathscale, and
gfortran support. The gfortran support has been patched into Debian's
cfortran.h independently, and of course Pathscale compiler and cygwin
support are not relevant to the build on Debian.
As cfortran maintainer I'd prefer to see you force use of the system
cfortran.h during the build, but if you don't want to go against
upstream in this way I understand. It is really a pity that the
cfortran author is no longer active in maintaining it; forks like this
are kind of getting out of control.
This comment from upstream, quoted in your other email, I'd like to
understand better:
> NetCDF includes it's own cfortran.h, which will be used in its build.
>
> Any cfortran.h on the system will not be used, it will be ignored by
> netCDF. The netCDF fortran API looks for, and uses, its own
> cfortran.h, not depending on it to be installed, or using it if it is.
Does this mean that the libnetcdf-dev package will ship its own copy of
cfortran.h somewhere (maybe at /usr/include/netcdf/cfortran.h or
something similar)? How does a Fortran compilation using libnetcdff
ensure that the compiler picks up that file (which it should do to be
consistent) and not /usr/include/cfortran.h ?
best regards,
--
Kevin B. McCarty <kmccarty@xxxxxxxxxxxxx> Physics Department
WWW: http://www.princeton.edu/~kmccarty/ Princeton University
GPG: public key ID 4F83C751 Princeton, NJ 08544
--
To UNSUBSCRIBE, email to debian-mentors-REQUEST@xxxxxxxxxxxxxxxx
with a subject of "unsubscribe". Trouble? Contact listmaster@xxxxxxxxxxxxxxxx
-------------------------------------------------------
--
Warren Turkal, Research Associate III/Systems Administrator
Colorado State University, Dept. of Atmospheric Science
==============================================================================
To unsubscribe netcdfgroup, visit:
http://www.unidata.ucar.edu/mailing-list-delete-form.html
==============================================================================
