Le Fri, Dec 05, 2025 at 09:57:54PM +0100, Marco van Hulten a écrit :
> On Fri Dec 5, 2025 at 6:41 PM CET, Landry Breuil wrote:
> > Le Fri, Dec 05, 2025 at 05:42:35PM +0100, Marco van Hulten a écrit :
> >> With NCO you can manipulate and analyse netCDF and similar files.  It is
> >> a useful addition to to tools that are already there.
> >> 
> >> So you could do this:
> >> 
> >>   wget https://cluster.klima.uni-bremen.de/~fmaussion/teaching/climate/CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc
> >>   ncdump -h CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc | head
> >>   ncrename -d month,mo CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc
> >>   ncdump -h CERES_EBAF-Surface_Ed4.1_Clim-2005-2015.nc | head
> >> 
> >> to rename the time axis.
> >> 
> >> Apropos, geo/cdo has some of the same functionality, but it is designed
> >> to handle data variables, not meta information like axes names, so
> >> geoscientists will quickly be looking for something like NCO.
> >> 
> >> OK to add this?
> >
> > from a first look, you'll need at least fixing the proper versionning
> > for the @so that should be @lib with the version, and a BDEP on
> > print/texinfo.
> >
> > @so lib/libnco-5.3.6.so -> that doesnt use the 0.0 from SHARED_LIBS.
> 
> I added print/texinfo (and see that this is needed).  I see that this is
> in pkg/PLIST.  There are no @lib entries.  Does that mean I do not need
> to include SHARED_LIBS?

well, it depends on what is the usecase for libnco. If it's a library
that's dlopened by binaries (eg generally what's called 'plugin') then
it can be a .so without versioning, but if it's a library things link
against (eg consumers of an api provided by the library) then the build
system should be adapted so that it is properly versionned with the
version coming from SHARED_LIBS, and available i nthe build env as a
variable (eg ${LIBnco_VERSION} iirc)

Landry