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

[Raphaël Pinson]

On Wed, Jan 28, 2009 at 7:53 PM, Raphaël Pinson <raphink at ubuntu.com> wrote:

>
>
> On Wed, Jan 28, 2009 at 6:19 PM, Jonathan Marsden <jmarsden at fastmail.fm>wrote:
>
>> Raphaël Pinson wrote:
>>
>> > Just tried packages from your PPA. It seems libsword7 should conflict
>> with
>> > libsword6, since they both provide /usr/bin/imp2gbs .
>>
>> Yes, thanks for the reminder!  In their current state, they should.
>>
>> We've talked on the list a litle about putting the tools into a separate
>> package say libsword-tools, or all into the diatheke package even -- but
>> there's not consensus in the group on doing that at this point.  Your
>> input would be appreciated, if you have an opinion and the time to join
>> the discussion!
>
>
> I think this is the safest approach : putting the tools apart from the
> library. That said, it means you might have to put the API version in the
> tools package name also, if you want to have two versions of libsword in the
> repository at the same time.
>
> Although this can be very useful, it will require much more work to
> maintain, and it would probably be much easier to have a list of all
> packages depending on sword and have them rebuilt each time there is an API
> break. Also, this might require to rename libsword-dev into libswordN-dev,
> if you want to be able to choose an API version to build a program in
> particular.
>
>
> My current (maybe naive?) thinking is that it would be helpful if, down
>> the road, one could install libswordN and libswordN+1 (indeed, for
>> libraries, I think this is much of why one embeds a SONAME version in
>> the package name itself!).  But the older libswordN (for N <=6)
>> packaging did not allow for this.
>
>
> No, and most libraries in Debian/Ubuntu are like that. For a good example
> of what you want to achieve, you can look into libmysqlclient, provided by
> the mysql source package. While it makes the system less strict, it also
> makes it more complicated. As an example, I often find myself making several
> versions of PHP5 for the various versions of MySQL in our repository (at
> work). There would have to be choices made on which version of sword to use
> with each program compiled on top of it.  If there is no need for such a
> thing, I don't really see the need for different versions of sword being
> installable at the same time (e.g. if there is absolutely no API breakage
> from one version to another, so that a program that builds on libswordN
> always builds on libswordN+1).
>
>
>
>> The libsword7 packages are definitely not ready for release yet; they do
>> seem to work fine for me and for Dima on machines without libsword6, at
>> least.  And my biblememorizer package sees them and uses them fine,
>> which is good (previously I'd only tested with diatheke).
>>
>
> I've tried them with biblememorizer from your PPA, and it worked fine. I
> had to remove libsword6
>

Ooops, not quite done yet (thank you Gmail keyboard shortcuts for sending my
message :) ). I had to remove libsword6 and all dependent packages
(gnomesword and bibletime included) to test though, due to the conflict.



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

I don't think you're making trouble. I think the main point is to know
whether it's worth it really. libsword is not a very widely used library
(probably less than 10 packages depend on it), so it's still quite easy to
rebuild all packages that depend on it when the API is changed.


><>

Raphaël
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-crosswire-devel/attachments/20090128/706889d2/attachment.html>