This is related to but not the same as bug 1484.  I actually think ldconfig is
probably working as designed here and no change is needed, but I'm not sure.

Suppose that you have a symlink

libfoo.so.1 -> subdir/libbar.so.1.1

where subdir/libbar.so.1.1 is the real file and libbar.so.1 is the SONAME.  This
is a variant on the arrangements in
http://sourceware.org/ml/libc-alpha/2003-08/msg00128.html
but in this case libfoo.so.1 is an extra compatibility symlink because we
suppose some programs expect that SONAME and libbar.so.1 provides the same
interface.  We reach the code

          /* If the path the link points to isn't its soname and it is not
             .so symlink for ld(1) only, we treat it as a normal file.  */

and it treats libfoo.so.1 as if it were an ordinary file like libc-2.5.so.  Thus
a symlink libbar.so.1 -> libfoo.so.1 is created and entered in the cache.

The "problem" is that libfoo.so.1 doesn't get entered in the cache under that
name; only the name libbar.so.1.  The same applies whatever name or link in the
subdirectory libfoo.so.1 is linked to.  This illustrates that there are use
cases where the soname should be entered (the above referenced message) but also
ones where the link itself should be entered under its own name.

Is the case given here something that should actually work?  If so, I have a
patch that causes both the link and the soname to be entered in the cache.  If
not, perhaps it should be made clearer what cases ldconfig supports.