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

[Rafael Laboissiere]

* Daniel Rus Morales <danirus at tol-project.org> [2008-02-11 09:44]:

> Rafael Laboissiere wrote:
> > * Adam C Powell IV <hazelsct at debian.org> [2008-02-10 13:07]:
> >
> >   
> >> Why not just use the whole library version in the soname and package
> >> name?  For example, libsuitesparse has lib*.so.3.1.0 which is the
> >> soname, and forget about .so.3 .  Then the soname and package name
> >> match, so lintian is happy, and if upstream changes the interface
> >> between 3.1.0 and 3.1.1 (let alone 3.2.0), the soname and package names
> >> change, right?
> >>
> >> This is what I do with petsc, spooles, hypre, parmetis, my netgen shlib
> >> patch, and will have to do for opencascade...  And it's lintian-clean.
> >>     
> >
> > Yes, this is the right thing to do for now, I think.  Thanks for the
> > suggestion, I will implement it in suitesparse.
> >   
> 
> But that's what indeed you did, isn't?
> I see that change in the 02-AMD_Lib_GNUmakefile.dpatch file.

Yes, I just committed the changes.  In 3.1.0-1, we had, for instance:

libamd.so.3.1.0: amd_global.oo $(AMDI_SL) $(AMDL_SL)
	$(CC) -shared $^ -lm -Wl,-soname -Wl,libamd.so.3 -o $@
	ln -s $@ libamd.so.3
	ln -s $@ libamd.so	

and now we have (upcoming 3.1.0-2 release):

libamd.so.3.1.0: amd_global.oo $(AMDI_SL) $(AMDL_SL)
	$(CC) -shared $^ -lm -Wl,-soname -Wl,$@ -o $@
	ln -s $@ libamd.so	

> I've just send an email to Tim Davis, the upstream author. While we wait 
> for an answer I think that what you did is better than the prior solution.
> Ayway I hope Mr. Davis will give us the chance to go further this. Let's
> see.

If Tim is willing to do it in a timely manner for lenny, then we might wait
for the upstream solution.  Otherwise, let'us keep the current solution.  At
any rate, it is not yet released to unstable.

-- 
Rafael