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

[Rafael Laboissiere]

* Andrey Romanenko <andrey at enginum.com> [2005-10-28 22:04]:

> 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. 

I do not agree with the arguments given by the upstream authors in the
URL above.  I think they are making a confusion between the version of
the software and the SOVERSION.  The later should be updated only when
changes in the API occur.  The proposal to have users set the SONAMe is
quite abstruse.

At any rate, I think we should respect the point of view of the upstream
authors.  They may have compelling reasons to have chosen this scheme.

> 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..

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.

-- 
Rafael