Bug 189734 - netcdf packaging with netcdf-3 subdirectory blocks use of netcdf
netcdf packaging with netcdf-3 subdirectory blocks use of netcdf
Product: Fedora
Classification: Fedora
Component: netcdf (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Ed Hill
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2006-04-24 00:18 EDT by Paul Johnson
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-04-24 01:31:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Johnson 2006-04-24 00:18:46 EDT
Description of problem:

The netcdf spec file inserts "netcdf-3" into the install path, 
claiming this will allow peaceful co-existance with netcdf version
4.  However, the programs we have that want to use netcdf cannot
compile because the netcdf headers and libraries are not under /usr/include
and /usr/lib in the way that programs expect.  

Version-Release number of selected component (if applicable):

How reproducible:

Install R, and then run "install.packages("RNetCDF") and you will see the
compile fail because it cannot understand the way you have packaged the netcdf

Steps to Reproduce:
1. yum install R
2. Open terminal, su to root, then type R
3.  At the prompt, type 

> install.packages("RNetCDF")

In X, it will ask you to choose a web server from a list.  In console, it will
ask you to type in a number of a web server. I like 57, personally.

Actual results:

Compile fails:

> install.packages("RNetCDF")
--- Please select a CRAN mirror for use in this session ---
Loading Tcl/Tk interface ... done
trying URL 'http://lib.stat.cmu.edu/R/CRAN/src/contrib/RNetCDF_1.1-3.tar.gz'
Content type 'application/x-gzip' length 50504 bytes
opened URL
downloaded 49Kb

* Installing *source* package 'RNetCDF' ...
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for executable suffix...
checking for object suffix... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for main in -lnetcdf... no
configure: error: netcdf library not found
ERROR: configuration failed for package 'RNetCDF'
** Removing '/usr/lib/R/library/RNetCDF'

Expected results:

I've rebuilt the netcdf RPM after changing the spec file to remove the "special"
re-location of the files and after that the compile works fine.

Additional info:
Comment 1 Ed Hill 2006-04-24 01:31:45 EDT
Executive Summary:  This is not a netCDF bug.  Its either a failure 
  of the build system for this particular software or its a symptom of 
  your failure to properly build it (eg. specify the necessary 
  include and/or library paths).  Please find someone who can help 
  you with the configuration.

Longer Explanation:

There are literally *dozens* of -devel packages that install their 
headers in subdirs such as /usr/include/${SOME_PKG}/ and/or their 
development libraries (esp. static libs) in /usr/lib/${SOME_PKG}/.  
But please don't take my word for it--go *look* for yourself.  Install 
a number of -devel packages on one of your systems and then take a peek 
in /usr/include and /usr/lib and see what you come across.

So, why are things done this way?  We don't we just dump everything in
/usr/include and /usr/lib and not have any subdirectories whatsoever?  
It turns out that there are good reasons.  And most of these reasons 
boil down to namespace pollution.  By separating the files into sub-
directories we can have a system with side-by-side installs of, for 
instance, multiple packages that export the same API using identically-
named headers.  And thats just one example.

What is lost by having these subdirectories?  In practical terms we 
loose nothing.  This is so because almost every build system on this 
planet supports one (and typically multiple) mechanisms that allow for 
the specification of additional include and/or library paths.  And the 
very few build systems that don't allow for user-selectable additional 
paths are rare indeed (and, by definition, are poorly written).  In 
those unlikely circumstances, the offending build systems can be either 
be worked around or fixed (patched).

Now, instead of trying to un-do the work that has already gone into 
packaging netcdf (and, because of the dependencies, nco, ncview, cdo, 
hdf5, etc.), please direct your effort towards the config/build 
system for your R package.  If you contact me personally, I'll be happy 
to help you with it.  Or, you could ask for packaging help on the Fedora 
Extras list:
where some folks already maintain R and various R add-on packages.

Looking at the R-RScaLAPACK spec-file in Extras I see that its 
easy to set additional paths within the R configuration and build 
system.  Heres the corresponding command for R-RScaLAPACK:

  %{_bindir}/R CMD INSTALL --configure-args="CFLAGS='$RPM_OPT_FLAGS
-I%{_includedir}/lam/ -L%{lamdir} -lutil -lmpiblacsCinit -lmpiblacs -llam
-llamf77mpi -lmpi -llapack' FFLAGS='$RPM_OPT_FLAGS -I%{_includedir}/lam/
-L%{lamdir} -lutil -llapack'" -l $RPM_BUILD_ROOT%{_libdir}/R/library %{packname}

and notice how it sets include/library paths, library names, etc.

Note You need to log in before you can comment on or make changes to this bug.