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

[Rafael Laboissiere]

* Daniel Rus Morales <danirus at tol-project.org> [2008-02-05 10:04]:

> Rafael Laboissiere wrote:
> >
> > I am afraid this will take much longer than is need for getting the gfortran
> > transition into lenny.  However, it does not cost anything to ask.  Would
> > you be willing to contact the upstream author on this issue?
> >   
> 
> I will do this, but you are right, it will take more time, so we need 
> another approach in the meanwhile.

Okay, I think we should go ahead with my proposal.  As I wrote in my first
post, my proposal is ugly, in the sense that we invent arbitrary soversion
numbers for the libraries, but I cannot see another simple way of coping
with the problem.

> Yes, I agree with you. Your proposal means more work but seems to be the 
> better way by now.

Why do you say my proposal "means more work"?  Any other solutions that I
could devise seemed to be imply more work.  I my be wrong though.

> At this moment I'd consider to split the package in as many libraries as 
> it has.

If you go down this road, then you will have to create packages with names
reflecting the sonames (libcolamd2, libcholmod5, etc), unless you do not
care about the soversion numbering.

> They share almost anything, and indeed they are available as separated
> tarballs. Then suitesparse-X.Y would be a virtual package which could
> increase the revision only when the backward compatibility were broken.
> This seems to be easier to mantain.

But how do you know that backward incompatibilities have been introduced
upstream?  This is the crux of the problem.  My proposal is simpler than
that because it will blindly create a new libsuitesparse-<version> package
for each new upstream release.  It is kinda stupid, but is simple.  BTW,
KISS [1].

[1] http://en.wikipedia.org/wiki/Keep_it_simple%2C_stupid

-- 
Rafael