[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: unclear policy regarding library names



> 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



Reply to: