[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [DebianGIS] Package of hdf-1.8.3, first try

On Thu, Jun 18, 2009 at 10:44:58AM +0200, Heiko Klein wrote:
> Hi,
> I'm eager to build a debian/ubuntu package of netcdf4 which requires  
> hdf-1.8.3. I've seen that it is on the todo list of this group, but  
> without explicit roadmap, so I gave it a try to build a hdf5-package:
> http://pastebin.met.no/pastebin/cgi-bin/file?id=afbf25c4b95a64a3ecf0e97ca4b713731f08f589/hdf5_1.8.3.orig.tar.gz
> http://pastebin.met.no/pastebin/cgi-bin/file?id=4e69a51659c8fa467ed66534b0e5105d2209a1d9/hdf5_1.8.3-1.diff.gz
> It was generated from the 1.6.5 debian package with uscan, and some  
> smaller changes to get hdf5 to build. The biggest change I introduce is  
> to name the library to the ABI version rather than the hdf package  
> version. hdf5 tries uses libtool and tries to be ABI compatible  
> (currently at library version 6) so I don't see a reason why the hdf5  
> packages should still force the correct version number.
> I have tested the package under hardy and debian 5.0.1. lintian gives  
> some complaints about man-page and the ABI-VERSION conflicts, but  
> otherwise it seems to work.
> I include the orig.tar.gz since the official hdf5_1.8.3.tar.gz contains  
> a file twice (detype_files.txt), which conflicts with debuild 'tar -xkf'.

Nice try. We have an ongoing discussion about 1.8.3 specifically about
the thread-safety and C++/Fortran. The reason for having a different
name is the following: the existance of the soname for the library is 
a recent discovery of HDF group. Unfortunately they use the same
soname for all libraries (C/C++/Fotran) so I think it's much more
safe embedding the library version into the package name. Note that
they often in the past changed API and ABI at every new release
and I suspect that would be done again if the C interface only was
left stable.

A good improvement would be dropping the unused (unuseful?) additional
ABI version in the package, which is what I did for 1.8.2.

But for that it is now time to issue a svn branch for the available
stuff in order to have a common reference for all available parties.

Francesco P. Lovergine

Reply to: