[Pkg-octave-devel] Re: SUNDIALS shared libraries

[Andrey Romanenko]

On Friday 28 October 2005 11:05, Rafael Laboissiere wrote:
[]
> The root of the problem comes from the way the libraries are generated
> upstream.  The authors use the -avoid-version option of litool when
> generating them.  This may be considered okay, but it is a very uncommon
> practice for libraries that are installed in /usr/lib/.
>
> Installing libraries in /usr/lib/ without a SOVERSION number is to ask
> for trouble in the future.  The scenario is like this: imagine that we
> build in the future the octave package depending on libsundials.  After
> that, suppose that there is a new release of libsundials with backwards
> incompatibilities in the API.  Since there is no SOVERSION numbers,
> upgrading libsundials (which occur without complaints by apt) will break
> octave.
>
> Of course, we can circumvent this problem by forcing the binary
> dependency of octave on a precise version of the libsundials package, but
> this is awkward.
>
> Even worse, dh_makeshlibs refuses to generate a DEBIAN/shlibs file for
> the package (hence the Lintian errors above).  This means the
> dpkg-shlibdeps will not work for packages depending on libsundials.  This
> will, at least, be annoying for the maintainers of those packages and, at
> most, induce the maintainers into error-prone methods to circumvent the
> absence of the shlibs file.
>
> All that can be avoided if we convince the upstream authors to use the
> -version-info and follow the instructions in
>
>     http://www.gnu.org/software/libtool/manual.html#Versioning
>
> as this is the current practice with C libraries.
>
> What do you (and the other DOG members) think?

I totally agree with what you say. Some months ago I even tried to talk with 
the upstream about this, see
http://www.llnl.gov/CASC/sundials/support/mailArchive/msg00042.html
and
http://www.llnl.gov/CASC/sundials/support/mailArchive/msg00044.html

The bottom line is, they prefer to have different versions of shared libraries 
to be in different directories. In the latter URL, Radu suggests that the 
user may set the soname. 

So, it may be a kludge, but it seems like the only way to enable 
SONAME/SOVERSION is to do it locally, in the Debian package. It calls for a 
very close watch on the libraries' API, though, which should be a packaging 
task..

Andrey