[Pkg-octave-devel] SUNDIALS 2.2.0 packaging

[Rafael Laboissiere]

* Andrey Romanenko <andrey at enginum.com> [2006-05-04 01:47]:

> I have just commited the first set of changes to build a Debian package of 
> SUNDIALS 2.2.0.

Thanks.

> - The new version has API versioning enabled, so I have deleted the lintian 
> override file. The problem is, all the API versioning numbers are set
> to 0. Now lintian complains about the name of the binary package not
> reflecting the SONAME. Should we rename it?

Yes, the package should be renamed to libsundials-serial0.

The package did not built correctly for me.  The generated libraries have
wrong names:

$ ls debian/tmp/usr/lib/*0*
debian/tmp/usr/lib/libsundials_cvode.0
debian/tmp/usr/lib/libsundials_cvode.0.0.0
debian/tmp/usr/lib/libsundials_cvodes.0
debian/tmp/usr/lib/libsundials_cvodes.0.0.0
debian/tmp/usr/lib/libsundials_ida.0
debian/tmp/usr/lib/libsundials_ida.0.0.0
debian/tmp/usr/lib/libsundials_kinsol.0
debian/tmp/usr/lib/libsundials_kinsol.0.0.0
debian/tmp/usr/lib/libsundials_nvecserial.0
debian/tmp/usr/lib/libsundials_nvecserial.0.0.0

Notice the lack of the "so" extension.  Investigating the issue further,
I discovered that the libtool script shipped in the upstream tarball does
not set the variable $shared_ext.  How did you succeed to build the
package correctly?

> - the new upstream include/ structure has subdirectories for each solver. 
> Besides, there is a sundials subdirectory for common stuff. Since we
> put include files in /usr/include/sundials, we end up with 
> /usr/include/sundials/sundials/*.h.

I do not think this is a problem.  On the other hand, the files ida.h,
kinsol.h, and nvector_serial.h are installed in /usr/include/sundials/.
Is this normal?

> - Lintian also complains about symlinks to the shared libraries in the 
> respective package. Should they go into the -dev package?

Yes.

-- 
Rafael