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

[Daniel Rus Morales]

Hi,

Rafael Laboissiere wrote:
> [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.
>   

Yes, that was the reason. I took the short way to code the SONAME. I'd 
prefer to use an schema based on current:revision:age (like Libtool 
suggest in [5]) but normally we don't know whether the API or ABI has 
changed and for that we can not evaluate whether we have to change only 
the revision or the current/age as well.

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

I'd prefer to contact the upstream author and suggest them to use the 
current:revision:age schema. If they were not in the mood, we could 
start in 0:0:0, and increase only the revision. The former is the 
better, the later at least let us to keep the libraries findable by 
other packages.

Daniel

> [3] http://lists.debian.org/debian-devel-announce/2008/02/msg00002.html
> [4] http://wiki.debian.org/GfortranTransition
>   
[5] -> http://www.gnu.org/software/libtool/manual.html#Libtool-versioning