Bug#509933: versioning SONAMEs of shared libraries is not ..

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-
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



--
To UNSUBSCRIBE, email to debian-bugs-dist-REQUEST DeleteThis @lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster DeleteThis @lists.debian.org