[Debian-med-packaging] libSBML versioning
Moriyoshi Koizumi
mozo at sfc.keio.ac.jp
Thu Jul 17 10:52:45 UTC 2008
Hi Andreas,
On Wed, Jul 16, 2008 at 6:37 PM, Andreas Tille <tillea at rki.de> wrote:
> 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 ...
Confirmed, thanks. I'm thinking of renaming libsbml1 to libsbml2
because its .so file is versioned like 2.x.x.
BTW, debian-med hosts the e-cell package separately from ours. I'm
more than willing to take it over. If there is anyone who is
interested in maintaining the e-cell package, I guess we better have a
talk so let me know.
>> 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.
The current stable release of E-Cell system is version 3, which
depends on libsbml version 2. So I'd rather make sure that libsbml
version 2 is provided indeed :) I hope someone will take care of
libsbml version 3. That would help me a lot.
>> 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.
<snip>
> 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.
I'd always choose consistency in the circumstances as long as they are
reasonable. If you find something irrelevant, please point me out.
Thanks for the guidance.
Regards,
Moriyoshi
--
Moriyoshi Koizumi <moriyoshi at gmail.com>
(also reachable on <mozo at sfc.keio.ac.jp>)
More information about the Debian-med-packaging
mailing list