Bug#509933: versioning SONAMEs of shared libraries is not clearly recommended
Package: debian-policy
Version: 3.8.0.1
Severity: minor
I read through the shared library sections of Policy a few times last night
and can't find anywhere where Policy unambiguously recommends always
including a version in SONAME for public libraries. If you don't have a
version, you can't represent the library in the shlibs format, so there's
an implicit recommendation, but I think it would be better to make it
explicit.
Note from:
http://lintian.debian.org/tags/shlib-missing-in-control-file.html
that KDE in particular has a ton of unversioned shared libraries, all of
which appear to be private libraries for particular applications and hence
already should be in a subdirectory of /usr/lib per existing Policy. The
other cases where shared libraries aren't versioned (which are currently
caught by that Lintian tag but soon will be caught by a new one) are similar
cases of misplaced plugins and private libraries, as near as I can tell,
with a few special cases.
I doubt this makes sense as a must since there are weird edge cases like
libSegFault, but I think a should is warranted. You need to really know
what you're doing if you're packaging a public shared library without a
version in the SONAME.
-- System Information:
Debian Release: lenny/sid
APT prefers testing
APT policy: (990, 'testing'), (500, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Kernel: Linux 2.6.26-1-686 (SMP w/1 CPU core)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
debian-policy depends on no packages.
debian-policy recommends no packages.
Versions of packages debian-policy suggests:
ii doc-base 0.8.18 utilities to manage online documen
-- no debconf information
Reply to: