in the RDEPEND section, there is a test to install wether sci-libs/netcdf or sci-libs/hdf, depending on wich useflag are set. || ( netcdf? ( sci-libs/netcdf ) hdf? ( sci-libs/hdf ) ) and in the src_unpack section, ther is a test to check if the use szip is set for sci-libs/hdf if useq netcdf && useq hdf; then einfo "Checking if HDF4 is compiled with szip..." if built_with_use sci-libs/hdf szip ; then einfo "Found HDF4 compiled with szip. Nice." else ewarn "HDF4 (sci-libs/hdf) must be compiled with the szip USE flag!" einfo "Please emerge hdf with szip USE flag and then emerge GDAL." die "HDF4 not merged with szip use flag" fi fi if ther is only 1 useflag between netcdf and hdf, the ebuild is working fine. but if you set the 2 useflag, hdf is not seen as a requirment in the RDEPEND section (and is not installed), but in the src_unpack section, there is a test on it, so the compilation failed with a die message: "Unable to resolve sci-libs/hdf to an installed package" REPRODUCTIBLE: on every gdal version with sci-libs/hdf not installed EXPECTED: in the src_unpack section, the ebuild should test if there is hdf and not netcdf, something like "if useq hdf !& useq netcdf; then"
From what I can tell, both hdf4 and netcdf can work with netcdf files, with some caveats; they also have collisions on certain tools, etc (hdf5 is another story). It would be convenient to drop hdf4 support, but due to legacy data sets, I don't want to take away anyone's tools, so the current "fix" is to die if both netcdf and hdf are enabled and ask the user to disable one or the other (since there should really be only one installed anyway). Feel free to test the latest 1.5.x update shortly, while I finish up 1.6.0.
