[Pkg-octave-devel] Re: SUNDIALS shared libraries
Andrey Romanenko
andrey at enginum.com
Fri Oct 28 21:58:58 UTC 2005
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
More information about the Pkg-octave-devel
mailing list