On Mon, 18 Dec 2006 07:48:52 -0700 Ed Hartnett <ed@xxxxxxxxxxxxxxxx>
wrote:
> Jeff Whitaker <jswhit@xxxxxxxxxxx> writes:
>
> > Warren Turkal wrote:
> >> The cfortran.h file is in /usr/include on Debian systems after
> >> installing the cfortran package. Does netcdf use a cfortran.h in
> >> /usr/include instead of the one within the tarball when it is
> >> available? If not, could you please change netcdf to do so for
> >> beta5?
> >>
> >> wt
> >>
> > Warren: Why? What if it is broken, or out of date? I'd rather
> > netcdf use it's own cfortran.h, which it knows it can trust.
> >
> > -Jeff
>
> 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.
>
> This is necessary: some modifications to netCDF's cfortran.h allow it
> to be built on even more platforms than the original cfortran.h
> allows.
Hi folks,
I can appreciate "both sides" of this issue! :-)
As a developer, its nice to sometimes use a locally included copy of
some 2nd-party software since, that way, you know its there and you
know exactly what version it is (inc. any changes you made to it).
As a packager for Fedora I can appreciate why most distros try to
eschew locally included copies of dependent software (usually libraries)
since they can be problematic:
1) security headaches (eg. that local copy of zlib that a
package includes is OLD and has known security holes which will
mean that an updated system-wide zlib package will totally fail
to fix your local problem)
2) unnecessary bloat
3) local copies are essentially "forks" which increase overall
maintenance costs and tend to slow the movement of fixes into
the respective upstream projects
Since cfortran.h is not a library, I think its quite unlikely to result
in security problems. And its a single file so not a lot of bloat. So
most of the reasons against local inclusion are mooted.
However, it would be a shame to maintain local improvements in the
"netCDF version of cfortran.h" without submitting them to the upstream
project so that everyone can benefit. If its possible [0], I would urge
the netCDF folks to work with upstream so that everyone can benefit
from any "netCDF local" cfortran.h improvements.
Ed
[0] - Yes, this assumes that "upstream" projects are actively
maintained and receptive to patches. Which is not always
the case...! :-/
--
Edward H. Hill III, PhD | ed@xxxxxxx | http://eh3.com/
Attachment:
signature.asc
Description: PGP signature
netcdfgroup archives: