> 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
