[Debian-med-packaging] libSBML versioning

[Moriyoshi Koizumi]

Hi there,

I'm one of the guys who tried to package libSBML version 2 in the
early months of the last year.

Since I managed to merge the efforts of multiple sources into one
patch, there seems to have been a kind of confusion and all the
language bindings were disabled tentatively when the upstream
development moved to version 3, which has qute different API than
version 2. Because I still needed version 2 packages in my project
(E-Cell), I personally continued to maintain the version 2 packages fo
my own sake. The packages can be found at
http://www.e-cell.org/ecell/software/3rdpartydist .

As my project began focusing on the version 3 releases, I was again
trying hard to make a complete set of the new packages with Perl,
Python, Ruby and Octave bindings reenabled so that I could publish it
for debian-med. Everything looked pretty well so far, except the
package naming / versioning issue. Because the API is different, I
don't think it's a good idea to keep the two in the same repository.
In addition, I think it's probable that the packages for the two
releases are provided separately at the same time: namely, libsbml2
and libsbml3.

How am I supposed to handle this situation? should I create a new
repository like trunk/packages/libsbml2? or better keep it as a branch
in trunk/packages/libsbml/branches something?

At this moment, debian files for libSBML 3.0 are maintained in the
following location:
http://chaperone.e-cell.org/svn/misc/debian.libsbml2/

and, debian files for libSBML 2.0 are maintained in the following location:
http://chaperone.e-cell.org/svn/misc/debian.libsbml1/
(nevermind of the wrongly versioned repository name :)

Besides, I'm still unsure about the documentation packaging; are they
supposed to be included in the development packages? when should I put
them into separete packages?

Any inputs are greatly appreciated.

Regards,
Moriyoshi

-- 
Moriyoshi Koizumi <moriyoshi at gmail.com>
(also reachable on <mozo at sfc.keio.ac.jp>)