[Pkg-crosswire-devel] Module dependencies

[Matthew Talbert]

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

This appears to solve the Arab Bible issue, and no, there are several
different kinds of modules besides Bibles.

> [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.

I think Recommends would be more appropriate.


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

Any module with this line "DistributionLicense=Public Domain" in the
module .conf file would theoretically be available for repackaging.
Modules without this line at all would also theoretically be
available, but I suspect it would be better to avoid them entirely.

> 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

It would be my preference that we save the discussion about whether we
should or shouldn't package modules until after this release. It would
also my preference that no additional modules would be added. Would
this be a compromise that we could move forward with? I really believe
that removing the dependency on having a module installed would remove
the biggest majority of support issues we've had.

Matthew