|
| 1 | +HDF5 for Debian, note for the mantainers |
| 2 | +---------------------------------------- |
| 3 | + |
| 4 | +The Debian version of HDF5 is created starting from the official tarball and |
| 5 | +adding some required patches managed by quilt. More information about quilt |
| 6 | +use are available in /usr/share/doc/quilt/README.Debian and its documentation. |
| 7 | + |
| 8 | +Note that starting from 1.8 HDF Group is not more providing a tarball of the |
| 9 | +library documentation. The documentation in html format is now taken by |
| 10 | +the HDF Group svn repository: |
| 11 | + |
| 12 | +svn export https://svn.hdfgroup.uiuc.edu/hdf5doc/branches/hdf5_1_8_4/html |
| 13 | + |
| 14 | +This is taken care by uscan companion script debian/orig-tar.sh. |
| 15 | + |
| 16 | +About symbols files |
| 17 | +------------------- |
| 18 | +To update the symbols files on new upstream releases: |
| 19 | +0- Rename and update the symbols files with the new sonames. This can be |
| 20 | + done with the script debian/update-symbols-files-soname |
| 21 | +1- Build the package for the new release |
| 22 | +2- Patch the symbols files from the dpkg-gensymbols output in the build log |
| 23 | + $ patch -p0 <path_to_build_log |
| 24 | +3- Use the debian/process-symbols-files script to unmangle and sort C++ |
| 25 | + symbols, and generate the version scripts (debian/map_*.ver) |
| 26 | +4- Rebuild the package and check that no diff are reported by dpkg-gensymbols |
| 27 | +5- Goto (2) if need be |
| 28 | + |
| 29 | +About version scripts (debian/map_*.ver) |
| 30 | +---------------------------------------- |
| 31 | +Their purpose is to be able to link serial and mpi flavors of libhdf5 |
| 32 | +into the same executable. |
| 33 | + |
| 34 | +I use the helper script make-version-scripts to generate them. I don't |
| 35 | +care about identifying local symbols for now. |
| 36 | + |
| 37 | +About C++ symbols tracking |
| 38 | +-------------------------- |
| 39 | +Tracking C++ versioned symbols is complacated: |
| 40 | +* Firstly we need to track them under their unmangled form to be arch |
| 41 | + independant. |
| 42 | +* Secondly I discovered after many /try fail repeat/ that dpkg-gensymbols |
| 43 | + wants the verbose unmangled symbols (output from 'c++filt' command) |
| 44 | + while version scripts want the non verbose ones (output from |
| 45 | + 'c++filt -i' command). |
| 46 | +* Finaly the patches generated by dpkg-gensymbols don't allow any |
| 47 | + comment in the symbols files and requires a specific sorting order |
| 48 | + (bug #773718). |
| 49 | +All these concerns are handled by three helper scripts: |
| 50 | +* debian/process-symbols-files |
| 51 | +* debian/sort-symbols |
| 52 | +* debian/make-version-scripts |
| 53 | +The entry point being debian/process-symbols-files. |
| 54 | + |
| 55 | +There was a non backward-compatible change in the C++ API between releases |
| 56 | +1.8.11 and 1.8.12 with no soname bump. Since there is no packages in sid |
| 57 | +using this C++ library, we didn't bother. |
| 58 | + |
| 59 | +The script debian/check-dep-on-hdf5-cpp is used to check these dependencies. |
| 60 | + |
| 61 | +About shared libraries versioning and SONAME |
| 62 | +-------------------------------------------- |
| 63 | +Worth reading to get the picture about libtool versioning: |
| 64 | +<http://bzed.de/scratchpad/soname-libtool.txt> |
| 65 | + |
| 66 | +[Old note - for the record] |
| 67 | +> About versioning style. In very recent times (since 1.8 series) HDF Group |
| 68 | +> introduced a libtool SONAME versioning in the library with major/minor releases. |
| 69 | +> Unfortunately, past experieces showed that API retention has been sometimes |
| 70 | +> violated in the past, so current packages use a defensive approach by considering |
| 71 | +> each release as not back-compatible. This is also motivated by the presence of |
| 72 | +> of C++ and Fortran bindings as well as multiple MPI editions, which could imply |
| 73 | +> ABI breakages even for minor releases. Be defensive is more safe, definitively |
| 74 | + |
| 75 | +Looking at the 1.8.x releases, it seems that upstream doesn't apply the |
| 76 | +libtool versioning strategy. Instead they use it the major.medium.minor way |
| 77 | +where: |
| 78 | +* medium=0 |
| 79 | +* minor++ on release |
| 80 | +* major++, minor=0 on API breaks |
| 81 | + |
| 82 | +Considering applying this piece of advice from Julien Cristau: |
| 83 | +> J'aurais tendance à suggérer d'utiliser le switch -version-number de |
| 84 | +> libtool plutôt que -version-info. Ça prend directement comme argument |
| 85 | +> major:minor:micro, donc on se perd pas dans des calculs à la con. |
| 86 | + |
| 87 | +Manpages |
| 88 | +-------- |
| 89 | +$ help2man -n "helper script to compile HDF5 Fortran applications" --version-string="h5pfc (hdf5 1.8.12)" -h -help -N h5pfc >debian/man/h5pfc.1 |
| 90 | +$ help2man -n "helper script to compile HDF5 C applications" --version-string="h5pcc (hdf5 1.8.12)" -h -help -N h5pcc >debian/man/h5pcc.1 |
| 91 | +$ help2man -n "debugs an existing HDF5 file at a low level" --version-string="h5debug (hdf5 1.8.12)" -N 'bash -c "h5debug 2>&1"' >debian/man/h5debug.1 |
| 92 | + |
| 93 | +TO-DO |
| 94 | +----- |
| 95 | +* common manpage for h5*{c,f}c |
| 96 | +* patch libtool usage to use -version-number instead of -version-info'? |
| 97 | +* propose to upstream to use a separate libtool version for each language |
| 98 | + (C, C++, Fortran)? |
| 99 | + |
| 100 | + -- Francesco Paolo Lovergine < [email protected]> Mon Jan 25 06:00:00 CET 2010 |
| 101 | + -- Gilles Filippini < [email protected]> Mon, 22 Dec 2014 01:50:39 +0100 |
0 commit comments