[Pkg-octave-devel] SUNDIALS shared libraries

[Rafael Laboissiere <rafael@debian.org>]

Hi Andrey,

I am taking a look at the SUNDIALS package.  I succeed to build and install
it, as well as compile and run one of the examples:

    $ cd cvodes/examples_ser/
    $ gcc cvdx.c -o cvdx -I /usr/include/sundials/ -lsundials_cvodes \
        -lsundials_nvecserial -lsundials_shared
    $ ./cvdx 

(although the numerical results obtained are slightly different for those in 
http://www.llnl.gov/CASC/sundials/documentation/cv_examples/node3.html#SECTION00031000000000000000)

However, we have the following Lintian errors:

E: libsundials-serial1: no-shlibs-control-file usr/lib/libsundials_shared.so
E: libsundials-serial1: no-shlibs-control-file usr/lib/libsundials_cvode.so
E: libsundials-serial1: no-shlibs-control-file usr/lib/libsundials_nvecserial.so
E: libsundials-serial1: no-shlibs-control-file usr/lib/libsundials_ida.so
E: libsundials-serial1: no-shlibs-control-file usr/lib/libsundials_cvodes.so
E: libsundials-serial1: no-shlibs-control-file usr/lib/libsundials_kinsol.so

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?

-- 
Rafael