On 10-01-15 20:59, Paul Gevers wrote: >>> I think you don't need to add the version to the dpkg-gensymbols call, >>> and if you do, why strip the Debian part of the version? Doesn't >>> dh_makeshlibs call dpkg-gensymbols itself? So if you try to override >>> anything, shouldn't the dpkg-gensymbols calls be BEFORE the >>> dh_makeshlibs call? This doesn't look right to me. Have you seen >>> https://wiki.debian.org/UsingSymbolsFiles where it describes a way to >>> create a symbols file that contains as much history as possible? >>> >> >> If the symbols file contains versions with the Debian revision lintian >> displays a error[1]. >> >> No dpkg-gensymbols must run manually. Without the separate call no >> symbol files found. With I can found the diffs in the buildlog. >> >> And yes dpgk-gensymbols must be running befor dh_makeshlibs. Changed. > > I will do some testing and come back to this. This is not my experience > with libraries and symbols files. I disabled the calls to dpkg-gensymbols in your d/rules file and I manually removed the symbols for 1.39.2 for libxmlrpc-c++8 that you already added and I find that the symbols files are created. Indeed, lintian complains, but that is fixed by generating the symbols files before the build such that you can also build on it later. Yes, you can then strip them with -v (as you have them now in the package). Really, no need for the override of dh_makeshlibs AFAICT. The reason why I wouldn't want to have this in the rules is the risk of being forgetting to update the symbols file the next time it needs to be updated. In the end that would lead to to strict requirements on the version. Oh, and by the way, your get-orig-source target is broken. If I run it now, the $DATE string does not match the date in the changelog. Paul
Attachment:
signature.asc
Description: OpenPGP digital signature