[sword-devel] Legitimate FTP Mirrors & Module Distribution Rights Question
greg.hellings at gmail.com
Thu Jul 26 13:34:18 MST 2012
On Wed, Jul 25, 2012 at 8:24 PM, Andrew Thule <thulester at gmail.com> wrote:
>>> On Wed, Jul 25, 2012 at 12:27 PM, Greg Hellings <greg.hellings at gmail.com> wrote:
>> It should. It does not. AFAIK it currently maintains no status
>> information on whether ABC came from site X, site Y, a local install
>> file, or was manually inserted into the install location. Since
>> modules are just a collection of files on a disk bound together by a
>> conf file, there is no way of preventing a user from unzipping a
>> module she received in email into the folder. If that module is named
>> ABC then InstallMgr will assume it is the same module as ABC from
>> source X and offer an upgrade if the local version is less than site
>> X's version.
> I think it does - here's how I think it does. In Linux at least, it
> seems to track version numbers in the .conf file. For example, I have
> an Inuktitut sword module whose version information is kept locally
> The 20120224005250 bit seems to be explained in InstallMgr.conf as
> being specific to a particular site.
> How I understand this then is that InstallMgr writes information about
> modules in the form of .conf files (in my case ink.conf) to the
> 20120224005250 directory. If there's a difference between the .conf
> file in the 20120224005250 and the .conf file in the site associated
> with 20120224005250 it means there's an update.
I believe your understanding is mistaken. When I pull up a newly
installed SWORD directory where I've just pulled down the master
repository list, refreshed CrossWire and Xiphos, and then installed
the KJV from CrossWire I can find no artifacts within InstallMgr that
reference which module was downloaded and where it came from. The
directories you're seeing with timestamps hold caches of the remote
For instance under ~/.sword/InstallMgr/20081216195754/ I find the full
list of all the .conf files that were pulled from CrossWire. But I
have only installed one of them. Moreover, there is a path underneath
modules/ that corresponds with where kjv would have been downloaded to
(modules/texts/ztext) but the kjv directory under that is gone.
I'd love for Troy to jump into this thread and say, "Andrew is right,
we do track the source of a module and the info is kept in
such-and-such a place". However, it never did support that even after
the InstallMgr was added and support was implemented for the master
repository list and such. Yes, it would be great if source repository
information was maintained. However, it never was and I have heard
nothing of a person stepping forward to implement it. In practice,
there is no need for it as the vast majority of repositories are
directly under CrossWire's control or the control of active members of
CrossWire. Those few repositories which are not have a tiny number of
modules. Thus, we just ensure that the module name is unique and then
there is no problem. If the world of modules available continues to
grow then someone might need to eventually add this functionality.
An even better way would be to explicitly support multiple installed
modules with the same name simultaneously. Currently there is not very
good support for installing two versions of the KJV, for instance.
Using the same mechanism that is found under the InstallMgr/ folder
and applying it at the installed folder level (and tacking on extra
folder(s) for local installation(s)) would allow me to have both the
KJV 2.3 from CrossWire and the KJV 2.4 from CrossWire Beta installed
in parallel. That update would also require front-end support to
differentiate between them, but it could be done.
But at present, unless Troy has altered InstallMgr and hidden the data
somewhere, there is _not_ support for knowing whether the KJV I have
installed came from CrossWire or CrossWire Beta except the reliability
of my own memory.
> Thus, when you install from a different source InstallMgr could see
> that you have a .conf file for that module (INK for example) (in your
> InstallMgr directory or subdirectory) delete it and put the new copy
> in a source directory from which it was downloaded establishing a link
> between the most recent download and the module.
> sword-devel mailing list: sword-devel at crosswire.org
> Instructions to unsubscribe/change your settings at above page
More information about the sword-devel