> A package of mine requires the libstlport library. This library installs > as: > > $ ls -l /usr/lib/libstlport* > lrwxrwxrwx 1 root root 16 Apr 3 12:54 /usr/lib/libstlport.a > -> libstlport_gcc.a > lrwxrwxrwx 1 root root 20 Apr 3 12:54 > /usr/lib/libstlport.so -> libstlport_gcc_41.so > lrwxrwxrwx 1 root root 20 Apr 3 12:54 > /usr/lib/libstlport_41.so -> libstlport_gcc_41.so > -rw-r--r-- 1 root root 2122252 Jan 6 12:21 > /usr/lib/libstlport_gcc.a > lrwxrwxrwx 1 root root 20 Apr 3 12:54 > /usr/lib/libstlport_gcc.so -> libstlport_gcc_41.so > -rw-r--r-- 1 root root 1017292 Jan 6 12:21 > /usr/lib/libstlport_gcc_41.so > > which has not the form described in the debian-policy which uses (chapters > 9 and 9.1 in the policy): > > <libraryname>.so.version
Nothing in policy 9 or 9.1 makes any mention of what form a shared library name should take. In fact, it says just they opposite: your package should install the shared libraries under their normal names Here "normal" means "whatever upstream uses". This is essential if you want to be able to run non-debian software. If upstream releases libstlport_gcc_41.so, and ISV Bob writes NiftyApp 2.1 which expects to find libstlport_gcc_41.so, it won't run unmodified on a Debian system unless that shared library exists under the same name. That's why you cannot change the name. > I wouldn't care much for the library not having the correct form except > for the fact that dpkg-shlibs is not able to recognise the library and so > fails to include it in the dependencies exactly because of that > non-conformance. File a bug against dpkg. Eric
