[Debian-med-packaging] libSBML versioning

Andreas Tille tillea at rki.de
Wed Jul 16 09:37:20 UTC 2008


On Wed, 16 Jul 2008, Moriyoshi Koizumi wrote:

> 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 .

This is great.  The project will show up at

    http://debian-med.alioth.debian.org/tasks/bio-dev.html

after the next cron run ...

> 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.

I'd regard libsbml packages as a very welcome enhancement 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.

This is surely possible.  The question is rather: Are there users for
all versions and do we have enough man power to support all of them.
Traditionally the latest version of a project is maintained in Debian
and there is often a period of transition where an older and a newer
version coexist.  To simplify this transistion keeping the version
number in the package name is a reasonable thing to do.

> 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?

Well, in the sense that we have one directory per package and libsbml1
and libsbml2 are packages that might savely coexist it sounds reasonable
to use different directories.  On the other hand it is basically your choice.
Debian is a Do-O-cracy [1] which means the doer (in this case you) decides
what gets done.  So feel free to implement whyt sounds most reasonable
to you.

> 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?

If it is a "large" amount of documentation it deserves a separate package.
IN the past I had several disputes with ftpmaster what means "large" because
there is no exact definition.  I'm personally a fan of putting the documentation
in a separate package if it makes any sense to read the documents in it
without the other stuff.  So as I said above - just decide yourself because
you will get different answers if you ask different people.  Just be guided
by common sense.

> Any inputs are greatly appreciated.

Kind regards and thanks for working on this

          Andreas.


[1] http://www.communitywiki.org/en/DoOcracy

-- 
http://fam-tille.de



More information about the Debian-med-packaging mailing list