Re: Library soversion numbers in SuiteSparse

[Rafael Laboissiere <rafael@debian.org>]

Hi Steve,

Thanks for your thorough comments.  I am not going to reply to all of them
because I think there is a misunderstanding here:

* Steve Langasek <vorlon@debian.org> [2008-02-09 10:53]:

> On Mon, Feb 04, 2008 at 02:42:29PM +0100, Rafael Laboissiere wrote:
> > As I wrote above, it will be a huge burden for us to properly take care of
> > soversion numbers.  Furthermore, the fact that the package ships with
> > separate components, each one neeeding its own soversioning, complicates the
> > problem.  Hence, splitting libsuitesparse into separate packages (e.g.
> > libcolamd2, libcholmod5, etc) will not help us, because the soversioning
> > burden would remain.
> 
> I don't understand what "burden" you're referring to.  You're packaging
> libraries -- it's your responsibility to keep track of soname changes
> upstream and make sure these are reflected in the package names.
> 
> It's not your responsibility as a maintainer to make sure that upstream's
> soname changes are appropriate, though in practice you should find out soon
> enough from users when an soname bump has been missed.

The problem with SuiteSparse is that the upstream author does not specify
the sonames at all.  The original makefiles only build the static libraries.
We patched the Debian package in order to build the shared libraries and the
sonames are chosen by us in a quite arbitrary manner.

Anyway, in the afterthought I am not convinced the solution I implemented in
libsuitesparse-3.1.0 (namely by naming all librairies lib*.so.3.1.0) is
appropriate.  If we followed my proposed scheme, when upstream will release,
say, SuiteSparse 3.2.0, then the libraries would be named lib*.so.3.2.0,
which will not necessarily work since the sonames will be kept the same
(lib*.so.3).

At any rate, I am happy I released libsuitesparse-3.1.0 to experimental and
not to unstable; we still have some flexibility to fix the eventual problems.

The royal way to cope with this problem is, as Daniel Rus Morales already
proposed, to convince the upstream author to specify the soversion numbers
in the upstream Makefiles.  A sub-optimal solution would be to carefully
specify the soversion numbers ourselves.  This is the "burden" I was
referring to.

-- 
Rafael