Suppose you've got these libraries (standard on a Debian system):

lrwxrwxrwx  1 root root     17 Aug 22 22:45 /lib/libncurses.so.5 ->
libncurses.so.5.4
-rw-r--r--  1 root root 373480 Jul 17 16:37 /lib/libncurses.so.5.4
lrwxrwxrwx  1 root root     13 Aug 23 18:15 /usr/lib/libtermcap.so -> libncurses.so

Then ldconfig will create, in addition to the /lib symlink above, this symlink:

lrwxrwxrwx  1 root root     13 Oct 14 23:43 /usr/lib/libncurses.so.5 ->
libtermcap.so

That's because it looks at libtermcap.so, sees that it isn't pointing to a file
with SONAME "libtermcap.so<VERSION>", and clears is_link.  So there appears to
be a library in /usr/lib which provides libncurses.so.5, so ldconfig creates the
symlink.

This is not really harmful except to Debian's packaging scripts, which complain
that they can't find a package which provides /usr/lib/libncurses.so.5.  But the
symlink is redundant, and it would be better not to create it.

This message gives some background on the current test:
  http://sourceware.org/ml/libc-alpha/2003-08/msg00120.html

Unfortunately the same thing that's supposed to handle a link named
libc-2.3.2.so also handles a link named libtermcap.so.

We only need a single symlink named "libncurses.so.5" (but for each supported
ELF class / hwcap / et cetera) in all directories ldconfig searches.  But that's
getting a bit too magic.  Is there any way to avoid this excess link?