[Pkg-crosswire-devel] Module dependencies

[DM Smith]

Norbert Bollow wrote:
> Matthew Talbert <ransom1982 at gmail.com> wrote:
>
>   
>>>> The applications don't know how the modules have been installed, they
>>>> just see them through the Sword API. After the modules have been
>>>> installed with a package manager or a Sword installer they are just
>>>> ordinary files to the Sword. If a Sword app is run as root it can
>>>> uninstall the files in any case (which may leave the package
>>>> management system in a broken state).
>>>>         
>>> Thanks for the info!  I believe that this means that the functionality
>>> which I think is needed is not implemented yet.
>>>       
>> I know you said we could discuss this at a later date, but roughly how
>> would you propose that the two systems cooperate?
>>     
>
> Ok, here's a brief proposal in bullet-point form:
>
>  * Let's decide that populating the /usr/share/sword directory and
>    maintaining its contents should be left entirely to the distro's
>    packaging system.  The directory should be empty or non-existent
>    in the common case that no modules are installed through the
>    distro's package manager.
>   

This is already the case.

>    If sword detects that there are modules in this directory,
>    sword should make them available to users, but *must* *not* under
>    any circumstances (not even when running with root privileges)
>    modify or remove them, just like the filesystem hierarchy standard
>    says that "/usr ... must not be written to."
>
>    http://www.pathname.com/fhs/pub/fhs-2.3.html#PURPOSE18
>   

While I don't disagree with this statement, running mkfastmod or 
installmgr as root will manage the content there.

We are talking about getting 1.5.11 into the freeze. There was some talk 
about getting 1.5.12 in there, but I bet it's not going to be released 
soon enough. Adding functionality to SWORD at this point would push it 
out even further.

The other way would be to patch 1.5.11 to have this behaviour. But I 
don't think this is all that do-able. Not much time, the code is 
difficult (at least to me), ....

>  * If it is felt that sword should provide the system administrator
>    with the functionality to make sword modules available to all users
>    of a computer without requiing these modules to go through the
>    distro's package management, such modules should be placed
>    elsewhere, not under /usr.  I would propose /var/lib/sword
>   
You can patch /etc/sword.conf (I think this is the file) to point to 
/var/lib/sword instead of /usr/share/sword. As far as I can remember, 
this is the only place that /usr/share/sword is known.

Can the permissions be set up to be for write privs for those in the 
"sword" group?

Perhaps this is the best situation.
>  * In addition to all of the above, each individual user should
>    of course still have the option of downloading or otherwise
>    acquiring modules themselves.  These are stored in ~/.sword
>   
This is as it is today. At least in part. I think the programs will try 
to write to /usr/share/sword (or wherever /etc/sword.conf points) and 
failing that use ~/.sword instead.

>  * In order to make the situation (with the different directories
>    where modules can be located) transparent to users who look for
>    the modules in their ~/.sword directory, I propose that libsword
>    should automatically generate symlinks in ~/.sword to any modules
>    which are available system-wide.  My proposal here is that these
>    symlinks would be what makes files in /usr/share/sword and
>    /var/lib/sword visible to libsword-using software, so that users
>    who know how to use 'rm' and 'ln -s' could use these commands to
>    choose a subset of the modules that have been made available
>    system-wide.
>
>  * If a non-root user chooses to use "remove module" in a libsword-based
>    program, and the module is installed system-wide, I propose that
>    what should happen is that the above-proposed symlink should be
>    removed.
>   

Again, thinking about the short term (i.e. the freeze) we are talking 
about 1.5.11, probably not 1.5.12. So, it is limited to what patches can 
be whipped up.

>   
>>> I think that the logical consequence of this is that the libsword7
>>> package which we're currently building should *conflict* with all
>>> module packages that we know of (forcing any such packages which are
>>> currently installed to be removed).
>>>       
>> Of course, users may not like their modules to suddenly disappear. Is
>> there a way to leave the actual modules there, but remove the package?
>>     
>
> Hmm... wouldn't that result in a situation which is even more broken
> than the current kind of brokenness which we're trying to fix?
>
> If it's worse to remove already-installed module packages than to
> leave them where they are, I think we can simply remove "sword-text,
> sword-comm, sword-dict" from the "Depends:" of gnomesword (and any
> other packages which list any of these as dependencies).
>
>   
>> Failing that, is there a way to notify the user to use his front-end
>> to re-install the Bibles (a note suggesting that the modules available
>> are probably newer than what he had might be helpful as well).
>>     
>
> This notification would have to happen when the users starts the
> front-end software for the first time after the upgrade.
>
> If the front-end software provided a mechanism to display such a
> message once when a user, who has previously been using an older
> version of the software, uses a new version for the first time 
> -- then we could use that mechanism.
>
> Blessings and greetings,
> Norbert
>
> _______________________________________________
> Pkg-crosswire-devel mailing list
> Pkg-crosswire-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/mailman/listinfo/pkg-crosswire-devel
>
>