[sword-devel] location of configuration information
Tue, 12 Feb 2002 17:38:08 -0500
With these 4 methods of specifying the location of data wouldn't it be
possible to share modules in a multi-booting system, as long as at least one
of those systems could read the others file system? That way you could
install whatever frontend you wanted on each of your operating systems and
install the modules on just one system putting pointers to the modules on
the other system/s.
This would save a lot of space for the users. I personally have a system
that boots 4 different operating systems and I don't want to install Sword
modules 4 times on the same system. That would take up way too much hard
Thanks for all the work put into this project.
> I don't think many people commenting on this subject know how sword data
> is located. We allow 4 different ways to specify WHERE the data is
> 1) current working directory
> 2) $SWORD_PATH environment variable
> 3) /etc/sword.conf: DataPath=
> 4) $HOME/.sword/
> Sword data can be place anywhere on your system. One of these 4
> mechanisms must be used to tell the engine WHERE your data lives. I
> don't think we need more mechanisms to specify WHERE.
> Does this make sense?
> On Tue, 2002-02-12 at 01:26, David White wrote:
> > That is why I would suggest using a configuration script of some kind.
> > Users should not have to be root to install Sword, and I assume Sword is
> > intended to work on a wide variety of platforms, which may have very
> > different directory hierarchy schemes. Thus it is important for Sword to
> > robustly support installation into any arbitary directory in a
> > filesystem.
> > David.
> > On Tue, 2002-02-12 at 02:56, Martin Gruner wrote:
> > > > Personally I would prefer 3 places for linux.
> > > > the main sword mods directory (/usr/share/sword) for system
> > > > modules (rpms and debs)
> > > > /usr/local/sword for modules installed by installmgr and untaring by
> > > > home directory under .sword for users.
> > > >
> > > > or at least, this is the way it has to be for debian so could it
> > > > supported.
> > >
> > > The problem here is that you have diffenent locations and different
> > > installation methods. Once somebody starts to mix them, he'll get into
> > > trouble. Therefore I suggest ONE location, and ONE method, which
should be a
> > > good installmgr imo. Would even be easier than installing a bunch of
> > >
> > > Martin