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

[Andrey Romanenko <andrey@enginum.com>]

On Friday 28 October 2005 22:35, Rafael Laboissiere wrote:
> > 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..

should => should not :)

> I think we have actually two choices:
>
> 1) Patch all the Makefile.in replacing "-avoid-version" by
>    "-version-info x:y:z"
>
>    This is quite easy to do, although we will have to change debian/rules
>    to run autoconf.  The problem with this approach is that, as you
>    wrote, it will yield a huge maintenance burden, since keeping track of
>    API is not an easy job for someone outside the library development.
>
> 2) Just let the package as is (eventually removing the "1" from the
>    name "libsundials-serial1")
>
>    This means that any package build-depending on libsundials-serial-dev
>    will not be able to use dpkg-shlibdeps and will have to set an
>    explicit (and maybe versioned) binary dependency on
>    libsundials-serial.  Breakage after package upgrades may (and probably
>    will) happen, unless we force a "=" dependency relationship.
>
> I think that option 2 is the "less bad" solution.

And that brings up another question: should we split the sundials package in 
several packages, something like 
sundials-cvode-serial
sundials-kinsol-serial
and so on and then have a virtual sundials-serial package with dependencies?
This would allow a finer control and dependency capabilities. For example, if 
CVODES gets updated, packages that depend on, say,  KINSOL should not be 
affected.

Andrey