[Pkg-crosswire-devel] Libsword - utils, examples, test and bindings

[Dmitrijs Ledkovs]

2009/4/12 Jonathan Marsden <jmarsden at fastmail.fm>:
> Matthew Talbert wrote, quoting me:
>
>>> ... my feeling is that overall it is better to leave the module
>>> creation tools in the main libsword7 package, so that everyone has
>>> them who might want to explore their use.  It's not as though they
>>> take up megabytes of disk space (at least under Linux).
>
>> Previously, diatheke was in its own package. It seems to me that it
>> should be moved into libsword with the rest of the utilities. It's
>> primary purpose these days is to help in module development, to see
>> exactly what the engine is returning for a particular reference in
>> order to troubleshoot. It's role for web stuff is nowhere nearly as
>> prominent (I haven't heard of anyone actually using it for that). This
>> probably raises the question of where to put diatheke.pl, which is (I
>> think) an example of how to use diatheke to create a web site. I don't
>> know where that should go. But I do feel that diatheke is a
>> tremendously useful tool for module developers and should be put with
>> the rest of the module creation utilities.
>
> diatheke is also a front end in its own right.  There is no other text
> mode SWORD front end that I am aware of.  And diatheke exists (and
> works!) on machine architectures on which I doubt the main GUI front
> ends will ever run (m68k, mips, etc).
>

Since diatheke is a front-end to sword it can be compiled and used
with different soname's (in our case different versions of the
library). The relationship between diatheke and libsword is one way
(diatheke depends on libsword). If in hypothetical case diatheke would
be shipped as a different source package it might not as well depend
on a particular version (e.g. higher than).

> However, historically diatheke has been packaged separately (since at
> least Ubuntu dapper), so current Debian and Ubuntu users expect it to
> exist as a separate package.  I'm not sure that it is worth changing
> that approach just because it is also useful to module creators.  In the
> best case situation, the developer of a new module does not need
> diatheke, they just discover and use the *2mod tools.  When they need
> troubleshooting and diagnostic help, they will (presumably) turn to
> documentation, which should direct them towards diatheke as a helpful
> additional tool to test their new modules with.
>

Let's consider Debian standards and not past experiences. We can
declare relationships between packages so that *2mod and diatheke
packages are pulled and installed for the people who need them. When a
pbuilder is run to build Xiphos there is no need to have *2mod
binaries installed in the chroot environment.

> I think there is much that is basically right about the existing
> (pre-2009) approach to packaging SWORD and related software and data.
> There are exactly 4 kinds of SWORD-related packages: (a) a backend
> library package (libswordX); (b) front end packages (whether GUI- or
> text- oriented, and one could imagine a future audio front end that
> reads modules to you, even!) which use the library to access SWORD data
> modules, and (c) module packages congtaining SWORD data modules which
> the library can access and present to a user via a front end
> application, and lastly (d) a package only used by software developers
> compiling software that uses the library (libsword-dev).
>

Let's have more emphasis on the (a) it's _not_ simply backend library
package. It currently has additional _optional_ & _extra_ tools which
are not _mandatory_ for a functional backend library and frontend
gui's.

Now let's have a peak into Debian Policy Manual, 8.2 Shared library
support files 3rd paragraph:

"Run-time support programs that use the shared library but are not
required for the library to function or files used by the shared
library that can be used by any version of the shared library package
should instead be put in a separate package. This package might
typically be named libraryname-tools; note the absence of the
soversion in the package name."

> In general, most users just install a front end application ( diatheke,
> BibleTime, Xiphos, ...) and the library is installed automatically as a
> dependency.  They can then either install some data modules from
> packages, or they can use installmgr or its GUI equivalent to download
> module data for themselves.
>

I consider installmgr as a front-end (limited to manipulating
modules). Hence in my view there _might_ be packages:

1) diatheke - a frontend
2) installmgr - a special frontend
3) *2mod & mkfastmod - tools useful for package creators.

But all 1) & 2) & 3) are small enough such that three packages will be
two too many. Hence I think -utils is ok for them.

> This is pretty clear, and pretty simple.  I think the benefits of
> changing that overall approach need to be very clear, in order to
> justify our making any such changes.  Bundling a front end (diatheke)
> with the library changes this model, doesn't it?
>

Totally agree. Bundling diatheke with the library is two steps back.

But converting diatheke to utils and merging other /usr/bins to create
a -utils package is clear indication that diatheke _is not_ a server
(as it used to depend on apache) and that there are a few tools that
are related to sword but are not that big. A package with name -utils
is far more attactive and might get more popcon simply because people
are curious to find out what those tools are.

> BTW, didn't we have a discussion about how to partition stuff from the
> SWORD tarball into binary packages, in February?  I didn't realize this
> was still something that needed further discussion for 1.5.11 packaging.
>  We now have such packaging in Debian experimental, based on the
> approach we took back in February.  That doesn't mean we *can't* revisit
> this, but it perhaps means we should be careful not to make unnecessary
> changes.
>

In February we were rushing things a bit, IMHO... hence fast decisions.

>
> Jonathan
>

ps. If a Debian package fails to build on any platform it's a bug and
must be reported to BTS ;-) Hence I expect all GUI programs to run
everywhere.


-- 
With best regards


Dmitrijs Ledkovs (for short Dima),
Ледков Дмитрий Юрьевич