<br><br><div class="gmail_quote">On Wed, Jan 28, 2009 at 6:19 PM, Jonathan Marsden <span dir="ltr"><<a href="mailto:jmarsden@fastmail.fm">jmarsden@fastmail.fm</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Raphaël Pinson wrote:<br>
<br>
> Just tried packages from your PPA. It seems libsword7 should conflict with<br>
> libsword6, since they both provide /usr/bin/imp2gbs .<br>
<br>
Yes, thanks for the reminder!  In their current state, they should.<br>
<br>
We've talked on the list a litle about putting the tools into a separate<br>
package say libsword-tools, or all into the diatheke package even -- but<br>
there's not consensus in the group on doing that at this point.  Your<br>
input would be appreciated, if you have an opinion and the time to join<br>
the discussion!</blockquote><div><br>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.<br>
<br>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.<br>
 <br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">My current (maybe naive?) thinking is that it would be helpful if, down<br>
the road, one could install libswordN and libswordN+1 (indeed, for<br>
libraries, I think this is much of why one embeds a SONAME version in<br>
the package name itself!).  But the older libswordN (for N <=6)<br>
packaging did not allow for this.</blockquote><div><br>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).<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">The libsword7 packages are definitely not ready for release yet; they do<br>
seem to work fine for me and for Dima on machines without libsword6, at<br>
least.  And my biblememorizer package sees them and uses them fine,<br>
which is good (previously I'd only tested with diatheke).<br>
</blockquote><div><br>I've tried them with biblememorizer from your PPA, and it worked fine. I had to remove libsword6 <br><br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
How hard (and how worthwhile) is it likely to be to get things to the<br>
point where the different versions of libswordN will coexist?  Am I just<br>
making trouble for myself by attempting that?  Several other library<br>
packages do seem to manage it... so I'm not totally nuts to be thinking<br>
this way... am I?<br>
<font color="#888888"><br>
Jonathan<br>
</font></blockquote></div><br>