Bug#643894: netcdf.mod in libnetcdf-dev incompatible with default gfortran version in sid

[Giacomo Mulas]

On Tue, 11 Oct 2011, Francesco P. Lovergine wrote:

> While I can understand perfectly that a simple rebuild would fix the issue,
> I guess some strict dependencies are simply missed in the netcdf source package,
> because this kind of problem should not be raised at all (i.e. current gfortran
> and libnetcdf-dev binaries should be not installable at all together).
> Someone that knows gfortran compiler better than me could probably
> point that problem.

It's not necessarily a gfortran only problem, it also happens if you use
other compilers (i.e. intel, pathscale etc.). Upon creating a .mod file the
compiler and abi version are recorded there, so that mixing object files
compiled with different abis (due to compiler or version) is not possible.

However, what you suggest is also not correct, because gfortran-4.4 is still
available in sid: the problem is just that it is not the default any more. So
it would be incorrect to "fix" the netcdf source file so that it is
uninstallable if you have a gfortran package > the number at which the
default was changed. Moreover, since the netcdf maintainer cannot know in
advance at which version number of the gfortran metapackage the default
gfortran will be changed, how can (s)he know what Conflict: to set?

IMHO, the least incorrect way of handling this should be that when the
default compiler gets changed, an important, or critical, or whatever bug
should be filed against all packages whose libraries and/or .mod files (in
the case of gfortran) are incompatible with the new default compiler
version, "waking up" the maintainer to recompile the package. In a very
large number of cases, since nothing more than recompiling would be needed,
this could be even done (or at least attempted) by NMUs.

By the way, again IMHO, it should be an important issue to guarantee, at all
times, that all libraries included in the distribution are consistent with
(which usually means "compiled with") the default compiler. For all users,
like me, who develop/maintain scientific (or other) software, this would
remove a great number of issues with e.g. codes segfaulting because some of
the libraries they use were compiled with a different compiler version (it
happens all the time, e.g. with lapack, atlas, blas, scalapack, blacs, 
fftw3...). So it would be really desirable (for me) for the policy to
mandate that a change of the default compiler triggers a recompile of all
packages including binary libraries (via automatic bugs filed on them).

Just my 2¢. In any case, I solved my personal problem recompiling the
packages that needed recompiling for my needs, the bug report was meant to
help others so that they did not need to waste the same time I wasted to
track and solve the same problem...

Bye
Giacomo

-- 
_________________________________________________________________

Giacomo Mulas <gmulas at oa-cagliari.inaf.it>
_________________________________________________________________

OSSERVATORIO ASTRONOMICO DI CAGLIARI
Str. 54, Loc. Poggio dei Pini * 09012 Capoterra (CA)

Tel. (OAC): +39 070 71180 248     Fax : +39 070 71180 222
Tel. (UNICA): +39 070 675 4916
_________________________________________________________________

"When the storms are raging around you, stay right where you are"
                          (Freddy Mercury)
_________________________________________________________________
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.