[Pkg-crosswire-devel] Packaging Sword modules

[Dmitrijs Ledkovs]

2009/1/28 DM Smith <dmsmith555 at yahoo.com>:
> 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


I've started to read all this and think about it and I came up with this:

Assumption: The native form of distributing modules is current zipped type,
the debs provided should provide the zipped modules period.

Then crosswire: continue to provide zipped modules as usuall.

And Ubuntu/Debian: take a few common and popular modules (<30) and created
a special type of packages:

in stead of sticking the modules file by file into random locations
(/_insert_flame_war_here/usr/share | ~/.sword) the resulting debs should do this:

1) During built time a zipped module should be produced.
2) At install time this zipped module should be added to the pool
3) This location should be registered with the module manager
4) module manager should be called
  - so that it notices the new pool location
  - so that it install it into the global location since it will have rights to write in /

Clear distinction:

_Texts_ are installed from _Modules_ by _Module_ management.

_Modules_ are installed to the local location by the _Distribution_ management.

Possitives for users:


-- 
With best regards


Ледков Дмитрий Юрьевич

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 270 bytes
Desc: OpenPGP digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-crosswire-devel/attachments/20090128/ccc6f5b3/attachment.sig>