Re: unclear policy regarding library names

[Gordon Sadler <gbsadler1@lcisp.com>]

On Fri, Apr 13, 2001 at 10:49:44AM -0400, sharkey@superk.physics.sunysb.edu wrote:
> > 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.
>
Not to nitpick, but.. you have to take into account some upstreams may
or may not follow careful so naming guidelines. Which is really an issue
with upstream...

But look at the tcl/tk 8.{0-3} packages. They are backward? compatible
but then again they aren't. So Debian maintainer tried various ways,
different include directories, slightly different so names, etc, to get
them to live happily on one system together.

There's also the current libssl issue. 0.9.6 and 0.9.6a provide 0.9.6
but apps built with 0.9.6, ie ssh-askpass, fail when run with 0.9.6a.
And the sonames are the same !?

> > 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.
>
I'm fairly certain some work has been done on this already, it's not
perfect yet -), but better than before.


Gordon Sadler