Re: Help needed with symbols index in package
* Eriberto Mota <eriberto@debian.org>, 2016-01-06, 21:28:
dpkg-gensymbols: warning: debian/libkpmcore1/DEBIAN/symbols doesn't
match completely debian/libkpmcore1.symbols
--- debian/libkpmcore1.symbols (libkpmcore1_1.9.50-1_amd64)
+++ dpkg-gensymbolsBiEPCo 2016-01-06 20:58:15.171645367 -0200
@@ -1195,3 +1195,23 @@
_ZZZNK27SetFileSystemLabelOperation8iconNameEvENKUlvE_clEvE15qstring_literal@Base
1.9.50
_ZZZNK29CreatePartitionTableOperation8iconNameEvENKUlvE_clEvE15qstring_literal@Base
1.9.50
_ZlsR11QTextStreamRK14PartitionTable@Base 1.9.50
+libpmdummybackendplugin.so libkpmcore1 #MINVER#
+ _ZTI17CoreBackendDevice@Base 1.9.50-1
+ _ZTI20CoreBackendPartition@Base 1.9.50-1
+ _ZTI25CoreBackendPartitionTable@Base 1.9.50-1
+ _ZTS17CoreBackendDevice@Base 1.9.50-1
+ _ZTS20CoreBackendPartition@Base 1.9.50-1
+ _ZTS25CoreBackendPartitionTable@Base 1.9.50-1
+ _ZTV17CoreBackendDevice@Base 1.9.50-1
+ qt_plugin_instance@Base 1.9.50-1
+ qt_plugin_query_metadata@Base 1.9.50-1
+libpmlibpartedbackendplugin.so libkpmcore1 #MINVER#
+ _ZTI17CoreBackendDevice@Base 1.9.50-1
+ _ZTI20CoreBackendPartition@Base 1.9.50-1
+ _ZTI25CoreBackendPartitionTable@Base 1.9.50-1
+ _ZTS17CoreBackendDevice@Base 1.9.50-1
+ _ZTS20CoreBackendPartition@Base 1.9.50-1
+ _ZTS25CoreBackendPartitionTable@Base 1.9.50-1
+ _ZTV17CoreBackendDevice@Base 1.9.50-1
+ qt_plugin_instance@Base 1.9.50-1
+ qt_plugin_query_metadata@Base 1.9.50-1
These aren't public shared libraries, are they?
If they're not, then you've just run into debhelper bug #205142 (and
probably also #653640).
There's a simple work-around: pass -X (with appropriate argument) to
dh_makeshlibs.
export PVER=$(shell dpkg-parsechangelog --show-field version | cut -d"-" -f1)
%:
dh $@
override_dh_makeshlibs:
dh_makeshlibs -- -v$(PVER)
No, please don't do this.
Unrelated to Jonathan's original question, but I noticed this in the
Lintian override file:
# For small packages, it is preferable to not have a shared library in a
# seperate binary package:
libkpmcore1: non-dev-pkg-with-shlib-symlink
This is serious policy violation. The shlib symlink must not be in the
shared library package. Size of the package is irrelevant here.
(Also, typo: seperate -> separate. :-P)
--
Jakub Wilk
Reply to: