[Pkg-scicomp-devel] Suitesparse development

[Rafael Laboissiere]

* Rafael Laboissiere <rafael at debian.org> [2009-05-08 10:39]:

> The tricky suitesparse 3.1 -> 3.2 transition is over.  It is time now to
> start packaging the new usptream release 3.3.0.  What is painful with this
> package is that upstream does not manage the SONAME
> 
> 1) Split the package into separate library packages

It is done now in a jumbo commit to the Git repository:

http://git.debian.org/?p=pkg-scicomp/suitesparse.git;a=commit;h=154ce228dc321c1bdb45a487febeae8621e79858

The explanations are in the commit log, but let me briefly discuss the
motivations for the changes.  When I was working on the package split, I
noticed that the information about the version numbers was scattered all
over the place.  Namely, it appeared in:

   - debian/control (at each "Package:" line and also as dependencies for
     libsuitesparse-dev and libsuitesparse-dbg)
   - debian/lib*.symbols (in the file name, for instance libamd2.2.symbols)
   - debian/lib*.install (ditto)
   - debian/patches/*.diff (as the soversion number that should be provided
     for the library)

I addressed the issue by centralizing the information in the Perl script
debian/library-sonames.pl that contains the following hash:

    %soversion = (
        AMD, "2.2",
	CAMD, "2.2",
	BTF, "1.0",
	COLAMD, "2.7",
	CCOLAMD, "2.7",
	CHOLMOD, "1.7.1",
	CSparse, "2.2.3",
	CXSparse, "2.2.3",
	KLU, "1.1",
	LDL, "2.0",
	UMFPACK, "5.3.0"
    );
    
This is the *_single_* place where the soversion number should be
entered. I took the version numbers provided in the */README.txt
upstream files.

There are some arcane code lines in debian/rules using $(foreach...) and
$(eval...) constructs that do all the magic.  Also, the patched
*/Lib/Makefile's do the right thing, by running debian/library-sonames.pl
to get the appropriate soversion number.

The package builds fine and is Lintian clean.  Please, give it a try and
tell me what you think.  Before it is uploaded, we have to discuss the
implications of this changes for the Debian distribution at large.  I
think that the Release Team must particpate the discussion.

-- 
Rafael