[Pkg-crosswire-devel] Module dependencies

[Norbert Bollow]

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.

   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

 * 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

 * 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

 * 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.

> > 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