[Pkg-scicomp-devel] Library soversion numbers in SuiteSparse

[Rafael Laboissiere]

[I am Cc:ing this message to debian-release; perhaps the release folks will
have some helpful comment on this.]

In the process of preparing the 3.1.0-1 release of libsuitesparse, I noticed
a serious problem regarding the soversion numbers of the libraries shipped
in this package.  The soversion numbers are not determined by the upstream
authors and they have been arbitrarily set to 1.2 in version 3.0.0 of
libsuitesparse (e.g. libcolamd.so.1.2).

When Daniel Rus Morales committed the changes for 3.1.0 in December, he
changed all the soversion numbers such that they match the version number
appearing in the */Lib/README.txt files (e.g. libcolamd.so.2.7.1)

Although this practice is highly discouraged [1], I think there are no many
other options left to us.  Choosing the soversion number is somewhat tricky
and a relative good understanding of the upstream changes is needed [2]. 
Finally, it is not our job as packagers to do it, it's upstream's.

[1] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#sonameapiabi
[2] http://sourceware.org/autobook/autobook/autobook_91.html#SEC91

Now, the idea of changing the soversion numbers for each release of
libsuitesparse is okay, in principle, but yields problems.  Let us consider,
for instance, the version of suitesparse currently in SVN.  It produces a
library file libcolamd.s0.2.7.1.  If we uploaded this version to unstable,
the users would get it installed in the next upgrade and then she would have
problems like this:

    $ lp_solve -max -mps /var/tmp/model.mps
    lp_solve: error while loading shared libraries: libcolamd.so.1: cannot open
    shared object file: No such file or directory

This happens because libcolamd.so.1.2 would be inadvertently replaced by
libcolamd.so.2.7.1 in libsuitesparse 3.1.0-1.  This is patently wrong.

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 propose then to adopt the following solution, which is quite ugly but
should work.  Let us create a new library package called
libsuitesparse-3.1.0 (I am not sure we should also have a new source package
named, say, suitesparse-3.1.0).  In this package, we include all the
libraries with soversion numbers superior to so.1, which was the number
chosen in libsuitesparse_3.0.0.  We must have, at least, lib*.so.2.* files,
such that the libsuitesparse-3.1.0 will not conflict with the libsuitesparse
package currently in unstable/testing.

This solution is ugly for two reasons, at least.  First, we will have to
create a new package for every new upstream version.  Second, even if there
will be no changes in the libraries' API and ABI, we will force all of the
reverse-dependent packages to be rebuilt in order to use the new version.  

Anyway, I do not see another simple and efficient way to cope with the
problem.  I am open to other suggestions though.

If there are no objections to my proposal, I will go ahead, make the
necessary changes in SVN, and upload the new package to experimental.
Remember that the soft freeze for lenny will happen soon [3]. We should then
hurry up with this, because it will involve a dormant period in the NEW
queue, besides the fact that suitesparse is a main knot in the complex g77
-> gfortran migration [4].

[3] http://lists.debian.org/debian-devel-announce/2008/02/msg00002.html
[4] http://wiki.debian.org/GfortranTransition

-- 
Rafael