[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 200104125: Minor typo corrections to netcdf 3.5

This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.

  • Subject: Re: 200104125: Minor typo corrections to netcdf 3.5
  • Date: Wed, 25 Apr 2001 13:48:33 -0600
Russ,

>Date: Wed, 25 Apr 2001 10:53:18 -0600
>From: Russ Rew <address@hidden>
>To: Morten Pedersen <address@hidden>
>Subject: Re: 200104125: Minor typo corrections to netcdf 3.5 

The above message contained the following:

> >From: Morten Pedersen <address@hidden>
> >Organization: ?
> >Keywords: 200104251115.f3PBFIL06192 netCDF 3.5
...
> >         If I build a library as a normal user on somere mote NFS permssion
> >         i run ito the following problem at install time.
> > 
> >         1) If I install in say for instance /usr/local I do not get
> >            permission to do that (fair enough
> >         2) Then if I su and become  root, I have the permssion
> >            to install the files in /usr/local, but as the install procedure
> >            creates the libs locally I now run into access problems on the 
> >            NFS partition as root on my machine is seen as nobody on the
> >            Server. I belive this is fairly normal NFS setup.
> > 
> >         Number 1 is as it should be. 2 is triggered by a FORCE on
> > LIBRARY dependcy line in rules.make. Is that really needed... just
> > curious. I would be happier if the archive was only updated when
> > needed. (It's OK if everything is reachived if one file changes)

The FORCE dependency reduces the risk of a user installing a bad version
of the library (e.g. without the Fortran API that they requested).  This
is inconvenient when building in a disk partition that disallows
superuser write access.

Off the top of my head, I can't think of an optimal solution.

Regards,
Steve Emmerson   <http://www.unidata.ucar.edu>