Bugzilla Bug 41146

As the ebuild is currently written, the library libmfhdf.a is not produced when
the package is emerged.  The reason is clear:

src_unpack() {
        unpack ${A}
        cd ${S}
        # collides with netCDF
        sed -i 's/\(^SUBDIR.*\)mfhdf\(.*\)/\1\2/' Makefile.in
}

Since the ebuild eliminates the lines mentioning mfhdf from the makefile, the
library is not produced.

I'm not sure why the developer thinks this is necessary (at least now).  I have
netcdf installed on this system as well, and the file libmfhdf.a is nowhere to
be found.  This includes looking at the listing produced by:

qpkg -l netcdf

As far as I can tell, the ebuilds will no longer collide if libmfhdf.a is
produced by the hdf-4.2.0 package, so the line in src_unpack() should be
eliminated, so that the hdf package produces a complete library install.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Created an attachment (id=25355) [edit]
Modified ebuild for hdf-4.2.0

Ebuild for hdf-4.2.0 modified to produce libmfhdf.a

The problem is not the lib, but several other files from netcdf which are
overwritten:

epm -V netcdf
..5....T   /usr/bin/ncgen
..5....T   /usr/bin/ncdump
..5....T   /usr/share/man/man1/ncgen.1.gz
..5....T   /usr/share/man/man1/ncdump.1.gz
..5....T   /usr/include/netcdf.inc
..5....T   /usr/include/netcdf.h

I decided to check for netcdf presence during installation and to remove these
files from the hdf tree before merging if netcdf is there.

Btw, please submit patches for ebuilds rather than ebuilds if you can, and
attach them as text files, not as binaries.

Thanks for pointing out this problem.
-r1 should be out soon.

Having worked with the package a little bit more, I have a suggestion:

Why not rename the offending ncdump and ncgen (and their associated man pages) to hdfdump and hdfgen, respectively?  The binary utilities actually come in handy, as the ncdump and ncgen that come with the netcdf package don't work with hdf4 files, while the ncdump and ncgen that come with the hdf4 package do.

Created an attachment (id=25828) [edit]
Patch to update the ebuild's handling of included netcdf files

Ok, so I didn't quite have it right before. Since the included executables do
provide some unique functionality for hdf files (ie. dumping information from
hdf files in a format compatible with ncgen), we should probably rename the
executables (and their man pages) so that a future install of netcdf doesn't
overwrite them.  I created a patch that performs the described functions and
performs them regardless of the presence of netcdf.

I'll just have to believe what you say about ncgen/ncdump because there's
nothing on the manual pages about hdf files at all - thank you for the patch,
you nearly got it (the manpages don't have .gz suffix yet at this time of
installation). Very nice idea, though, will be in portage as -r2 soon.

Created an attachment (id=28034) [edit]
Another way to resolve netcdf conflict and ...

Resolve netcdf conflict in configure;
IUSE to szip;
versions included in dependence packages;
Maybe we should include gcc-3.3 in dependeces too. I remember that there are
some problems at mh-linux with gcc-3.2

Please re-open a bug whenever you add comments to a closed bug, otherwise this
easily gets unnoticed. Will have a look at this later.

Maybe we should have a global szip USE flag since opendx could also utilise
this. Just mailed an RFD to gentoo-dev.

Made szip optional now. I would like to know more about gcc version problems
before stating this as a dependency.