[Pkg-crosswire-devel] Module dependencies

[Jonathan Marsden]

Matthew Talbert wrote:

> The biggest issue to me is to remove the dependencies on the modules.
> An English speaker should not be forced to have an Arabic Bible and an
> Arabic speaker should not be forced to have an English Bible. This
> leads to a lot of support requests.

I understand this is a hot button issue.  I was waiting for someone
other than me to start work on updating a frontend before dealing with
it, but ... OK.

Every Sword bible module (not all modules are bibles, at least from what
I can see) can be packaged so as to do Provides: a virtual capability,
say "sword-text", and then each front-end package can Recommends:
sword-text, which will be fulfilled by any one of the (packaged) bible
modules.  No requirement for speakers of language X to install a bible
in language Y is implied by this at all.

[Aside for techies: this is like all MTAs doing Provides:
mail-transport-agent and then mail clients like mutt do Recommends:
mail-transport-agent rather than Depends: sendmail or whatever].

There *are* some wrinkles with this (because package managers handle
fulfilling virtual dependencies in sometimes unexpected ways) that need
to be understood, I am fully aware of that -- which is why mutt does
Recommends: exim4 | mail-transport-agent -- but we can deal with that.
We might (for example) need to end up doing something like Recommends:
sword-kjv | sword-text to help package managers make a sane default
choice if the user fails to select a bible module themselves.

Further, by using Recommends: rather than Depends: we avoid any
appearance of "forcing" anything.

The accidental "Arabic bible by default" thing in current packages of
some Sword frontends sounds to me like a pure and simple packaging
mistake, or at best an unfortunate packaging decision given the way some
package managers handle meeting virtual dependencies -- not a necessary
thing that is implied by the very fact of doing any module packaging.
Was this bug reported in Debian BTS or LaunchPad?  I sense that some in
the Sword/Crosswire end-user community may see it differently, and may
now associate any kind of module packaging with this unfortunate issue
-- but I don't really understand why that is a valid way to look at this.

Bottom line on this for me: Let's fix the bug; let's *not* use the
current existence of a bug as a reason to never package the data!

> On packaging modules, note that there is no good place to draw the
> line about which to package and which not to.

I disagree, see below for some possible approaches.

> Some modules debian wouldn't be allowed to distribute because of
> licensing issues (quite a few modules). There are several gigabytes
> of modules available in various languages. How do you pick which to
> package and which not to?

I need to look at some of the modules more, but if they are all simply
data and all work "the same way", then it may well be feasible to script
their packaging, and package all 300 or so of them (well, the subset of
those which can legally be packaged and redistributed) automatically, or
at least mostly-automatically.  That avoids your "which to package"
issue by answering "all of them"!

This would be especially true if we can grab descriptions of each module
from the Crosswire web site or some other module database, and if we can
get licence and copyright info for each module in a similarly automated
way.  If not, there is a rather boring manual data entry task looming,
but even that is not impossible.  We're a team, perhaps someone or even
several people among us will feel called to help with that, should it
become necessary.

Failing that, after excluding all modules that cannot be freely packaged
and redistributed for legal reasons, one could (for example; I am not
actually proposing any of these at this early stage):

(1) Decide to package all bible modules but not commentaries and other
non-biblical text modules, or some such distinction.

(2) One could initially package all bible modules in languages spoken by
more than N people (where N might be say 10 million for the first pass,
then 1 millon for a second round...).  We could use SIL Ethnologue data
for numbers of speakers, or other sources.

(3) Alternatively, one could perhaps obtain module download popularity
data from the Crosswire website logs, and use *that* to prioritize
module packaging.

You may well have other ideas too, these are just examples off the top
of my head.  There are surely *plenty* of possible (and reasonable) ways
to prioritize this work, if it turns out that we need to prioritize it.

First, though we need someone to start working on updating a front end
package or two... most end users will want more that diatheke to read
their online bibles with :)

Jonathan