Bug#1121629: libhdf4 FTCBFS: multiple reasons

[Sebastiaan Couwenberg]

Control: tags -1 pending

Thanks for the patch, it's applied in git.

On 11/29/25 1:19 PM, Helmut Grohne wrote:
> Once fixing these, the next build failure arises from running the built
> ncgen. I am not familiar with this tool, but it ends up getting
> installed into hdf4-tools, which is marked as Multi-Arch: foreign. This
> suggests that we should likely be using the installed version for cross
> builds only. Do you concur here?

To be honest, I'm not sure. I'm very far from fluent in cross-building.

The package contains a mix of scripts and binary executables, the latter should use the libhdf4-0 from the same architecture.

At least ncgen is executed as part of the test suite which suggests you need the installed version for cross builds if I understand cross-building correctly, or nocheck.
  
> In any case, I think we should defer the surgery about ncgen until after
> the migration to CMake has proceeded. This bug report is not meant to
> cover the ncgen aspect.

You should definitely try to spend as little time on this package as possible.

HDF4 is legacy software, upstream has its focus on HDF5. I only maintain the package because it's a dependency of gdal, I don't actually use it myself.

There is still HDF4 data out there, and people having a need for libhdf4 as proven by Antonio Valentino's work on python-hdf4 which is used by his remote-sensing related packages.

As a non-user of hdf4 I'm not sure about the value of the hdf4 variants of the tools also provided by netcdf like ncgen, I suspect users need those because netcdf is based on hdf5 so its tools only work those newer formats.

I suspect your work on hdf4 is to make (re)bootstrapping the key package set possible in which hdf4 finds itself thanks to gdal/opencv/ffmpeg, the opencv dependency is a bit unfortunate because it makes gdal a much more significant package then it deserves to be. GDAL is one of the core libraries in the geospatial world, but in the wider Linux world it most definitely is not.

Kind Regards,

Bas

-- 
  PGP Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1