crtm-fix - consistent suffix for NetCDF files

[climbfuji]

@climbfuji This issue can be closed, as the issue reporter determined that crtm_fix/package.py in the spack-stack-dev branch is updated from that of the release/2.1 branch recipe, and installs fix files as expected.

That said, two questions:

Lines 54-56 of the spack-stack-dev branch package recipe state that Everything below is legacy code that will be deprecated (removed) by the end of 2026 -- what will be changing?

Some netCDF-formatted fix files are tagged with a suffix of .nc and some with a suffix of .nc4. Should .nc4 files be denoted with a .nc suffix when symlinked?

Originally posted by @rickgrubin-noaa in #2073

[climbfuji]

@climbfuji's answer

Glad to hear that we apparently solved that earlier. I remember fixing this package several times, and Alex R. too.

The legacy code will go way = the symbolic links from the nested directory structures will no longer be created. They are dodgy at best, because one can either link big endian or little endian, and for some files there are even two versions for the same endianness.

Applications will be expected to look for the files in the corresponding subdirectories instead.

Or transition to the netcdf files. With crtm 3.2 (?) and corresponding crtm-fix, there will only be netcdf files anyway.

nc4 vs nc - would be nice to be consistent. Ideally upstream in future releases (@BenjaminTJohnson). If we know what the unique suffix will be in future releases (nc4 or nc), then we can create symlinks in the older releases as needed.