[Pkg-crosswire-devel] Packaging Sword modules

[DM Smith]

Jordan Mantha wrote:
> On Wed, Jan 28, 2009 at 7:29 AM, Daniel Glassey <dglassey at gmail.com> wrote:
>   
>> On Wed, Jan 28, 2009 at 2:27 PM, Jonathan Morgan <jonmmorgan at gmail.com> wrote:
>>     
>>> Before thinking about packaging Sword modules, I think we need
>>> understanding of why more core developers (including myself) tend not
>>> to favour it.  Feel free to comment or add to them (or counter them).
>>> Some of these reasons have already been mentioned, but here are my
>>> reasons.
>>>       
>> [imho many good reasons]
>>
>> Thanks Jonathan,
>>
>> The history behind the packaging of modules was that when the
>> packaging was started there was no such thing as installmgr or the
>> frontend module installers. Users had to go to crosswire.org, find the
>> zip they wanted, and extract in the right place.
>>
>> There was also the little matter of one of the frontends crashing if
>> you didn't have at least 1 bible, 1 commentary and 1 lex-dict!
>>
>> So I attempted to package a fairly minimal set. Folks in Ubuntu have
>> taken a different view since then which I would like to hear :)
>>
>> I think the ability to package modules will be useful for custom
>> distros like Ubuntu CE or Ichthux but personally I don't think it is
>> appropriate to have the packages themselves in distros now.
>>     
>
> In Ichthux we packages up a lot of modules because we had the ability
> to install sword modules as a part of the language selection at
> install. This means that people around the world had the possibility
> of having automatically localized Bible experiences. We thought that
> would be a nice addition. We were also concerned about people without
> internet connections so we wanted to have at least the basics on the
> CD itself.
>
>   
>> I think the fact that we can't package all the modules would really
>> confuse users. I agree that it's important that users have the full
>> choice.
>>     
>
> I think the only really confusing part is if you install via a package
> it doesn't show up as installed in the module managers, i.e. if I
> install sword-text-kjv and then look in the module manager I don't see
> KJV as installed. If we could somehow fix that I think it'd make mixed
> distro/crosswire installation less confusing.
>
>   
>> An alternative to packaging them in the distros is to distribute
>> packages from crosswire.org.
>> I, er, did try something like that before ages ago - creating a script
>> that would run in a cron job and create all the modules on the server
>> - but crosswire.org was a Red Hat machine (now Fedora) and creating
>> debian packages meant building and installing stuff locally which
>> wasn't maintainable.
>> If it is easier to build debs on Fedora now then I think that would be
>> the place to host them rather than inside Ubuntu and Debian.
>> Another way to host them on crosswire.org would be to automatically
>> build newly detected versions offsite on a deb system and upload them
>> back to crosswire.org - as long as that could be done securely.
>> This would be to give users a choice - add a package repo and install
>> them to system through the system package manager to /usr/share/sword,
>> or to use the frontends to install to ~/.sword or
>> /usr/local/share/sword.
>>     
>
> If we're hosting .debs on crosswire.org why wouldn't we just put then
> in Debian to start with?
>   

The advantages of hosting module .debs on crosswire.org:
Since crosswire.org is hosting them they could potentially provide all 
modules, including the ones restricted to CrossWire alone. As far as I 
know, CrossWire can deliver modules in any kind of package without 
violating any of their copyright agreements.
CrossWire can handle updates more quickly.
CrossWire can handle take downs more quickly.
CrossWire could manage the .debs programmatically and daily.
CrossWire can maintain statistics on downloads accurately (which some 
publishers request as a condition of their copyright agreement).
CrossWire does not have to handle support request concerning other 
repositories. (E.g. how do I index the module for advanced search; how 
do I delete the Arabic Bible; why was the Arabic Bible installed; Why 
can't I delete the KJV module but I can delete the ESV; Why does the 
install manager in BT show that a module has an update, but I can't get 
it from the package manager. How come the install manger show more 
modules than the package manager? ....)
(I bet we can come up with others.)

>   
>> Distros aren't just targeted to single users but should be useable on
>> multi-user systems as well, whether family, school, bible college or
>> whatever. So we need to take that into account whether or not it's the
>> primary target.
>>
>> I would guess most users won't be using apt-get - they'll be using the
>> graphical package manager which is a very different experience from
>> installmgr.
>>
>> Another use case for (imho a minimal set of) packaged modules is when
>> you get a distro CD/DVD with a sword frontend on it and aren't online
>> - what should you do?
>>     
>
> I think that was an original concern.
>   
In addition to using the Install Manager to download modules from the 
CrossWire repository there is another way that CrossWire provides modules:
Anyone can get all the CrossWire modules on CD. The program's install 
manager can install from that CD.
They can order it for a small shipping and handling fee or download the 
ISO and burn it themselves.

Any individual is welcomed to create copies and to distribute it.

Speaking officially for CrossWire community, this is how we want it. We 
do not want the modules to be distributed in another fashion. Please 
honor our wishes.

> Overall I don't see why it should be an issue to package up sword
> modules. IMO, the module packages should kept up-to-date as always and
> like many other such module systems the packaged modules should show
> up as "installed" in the application's module manager. Wouldn't that
> basically resolve most of the issues?
>
> I personally would rather use the Debian/Ubuntu archives to get my
> modules but I realize that we can't package everything because of
> copyright/license issues.
>
> -Jordan
>