[Pkg-crosswire-devel] peaceful coexistence of libsword6 and libsword7

[Jonathan Morgan]

On Thu, Jan 29, 2009 at 8:26 AM, Peter von Kaehne <refdoc at gmx.net> wrote:
>
>>
>>     How hard (and how worthwhile) is it likely to be to get things to the
>>     point where the different versions of libswordN will coexist?  Am I just
>>     making trouble for myself by attempting that?  Several other library
>>     packages do seem to manage it... so I'm not totally nuts to be thinking
>>     this way... am I?
>>
>>     Jonathan
>
> Wrt worthwhile - TBH I see no real benefit.
>
> What do we have for Linux:
>
> Gnomesword/Xiphos (Gnomesword's new name as of today)
> BibleTime
> diatheke
> BpBible
> Biblememoriser
> Bibledit
> glosung
> SwordWeb
>
> Of these Swordweb is in no fit state to get packaged,
> glosung and Bibledit collaborate with Sword programmes but do not
> require them (or do not require any particular version of libsword)
>
> You are left with 4 frontends and Biblememorizer.
>
> Within CrossWire we keep releases
>
> a) linked to the last released libsword
> b) update more or less at the same time to noe libsword.
>
> I think it would be long term more useful to keep all these in sync -as
> we do so anyway at CrossWire. I can not see any relevant situation where
> we would end up with the actual requirement of having two libraries
> present.

Due to the lengthy upstream release cycle, BPBible relies on a patched
version of 1.5.11.  It also relies on the Python SWIG bindings, which
I don't believe are included in the current libsword, and am not sure
whether you would want to package them with libsword or as separate
Python packages depending on libsword.

Unfortunately, I am informed by the SWIG maintainer that the SWIG
bindings will not even compile under SVN, so a quick release including
the patches against 1.5.11 won't help here.

I don't know what the policy is concerning distributing patched
versions of a library, but we have no hesitation at all in basing
BPBible on a patched Sword library, since we do not have to wait
months or years for an upstream release.

Jon