[Pkg-crosswire-devel] Module packaging, distribution, and management

[Eeli Kaikkonen]

Jonathan Marsden wrote:

> 
> Therefore, libsword and its related data packages "should" store that 
> kind of data in a subdirectory of /usr/share/.  Indeed, the sword 
> tarball docs are 100% consistent with this, recommending use of 
> /usr/share/sword/ for module data storage.  So far, so good -- 
> everything is in line with the standard.
> 

But see also the /usr/ and /usr/local/.

> 
> Possibility #1:
> 
> (1) Maybe the module manger UI(s) currently used do not make clear to 
> end users which of the modules they can see are in shared, read-only 
> locations and which are in per-user, read/write locations?  Making that 
> clearer could help reduce user confusion (users would be less likely to 
> try and remove a module using the Remove button (or whatever) if that 
> button were greyed out when a module in a read-only location is selected 
> (for example), or (better) it pops up a message that explains that this 
> module was installed by a system admin and is read-only, so it should be 
> uninstalled (or updated, or whatever) the same way it was installed.
> 

This is reasonable and while rewriting the module manager of BibleTime I 
have tried to take care of things like these. I will think about this.

> 
> Possibility #3:
> 
> A step up from #2 would be for the "module manager" to actually 
> integrate more fully with the system package management tools, and so 
> seamlessly allow end users to manage such packaged modules (prompting 
> for enhanced perms as needed, of course).
> 
> This is, of course, quite a lot of work!
> 

Too much.

> Possibility #4 (sort of):
> 
> An alternative would be for a "module manager" in front ends to totally 
> ignore all shared read-only modules, which most likely would include all 
> package-managed modules; this is very imperfect indeed, but at least the 
> two systems do not both try to manage the same set of data this way.
> 
> It feels ugly, but I think this needs relatively little implementation 
> work upstream, and no API changes at all (module managers need no 
> knowledge whatever of package management systems).  We could even patch 
> this approach into the packaged GnomeSword and BibleTime at package 
> build time ourselves, and even into installmgr -- but that's a 
> divergence from upstream behaviour we should strive to avoid.
> 

You will surely earn the hatred of the upstream developers if you do 
that. Knowing the community, I assure that you don't want it.

> 
> Suggestion: #2 sounds like a doable enhancement to the module manager(s) 
> to me; make the module manager aware of system package management, but 
> not actually able to work with such package management.  Is an 
> enhancement request to that effect likely to be acted on by the upstream 
> (CrossWire) development team?
> 

Not very likely. The idea is not bad but resources are scarce.

The most simple solution would be something like this: add a file in 
sword/mods.d/ which is updated when the package manager installs or 
removes a module. It has just a list of the names of the modules 
installed by the package management. The library would read the list and 
would provide a function to ask the state of a module. Frontends would 
be responsible of using this data.

But this wouldn't really give much advantage over just warning the user 
that the module is unremovable because of lacking privileges and may 
have been installed by the package management system.

>> If the modules are only suggested everything works fine:
> 
> Only up to a point; on a multiuser system or a networked setup with a 
> shared readonly module data location, if the module manager as run by an 
> end user remains blissfully unaware of the fact that some modules are in 
> read-only space,  users will try to "manage" these modules, because they 
> look just like all other personal-only modules in their module manager 
> -- then the user will be confused at the errors which they will get, I 
> suspect.
> 

But then the user hasn't installed those modules and doesn't think they 
are freely removable. It should be enough to give a hint in the install 
manager that those modules are in a read-only location and can't be 
uninstalled by the ordinary user.

BTW, if there are non-removable modules in a multiuser system, a 
BibleTime user can still remove the path in the module manager. The 
paths are stored in a user specific file in the home directory (by the 
Sword library). This affects all Sword applications. The modules will be 
there but they are not used at all. Another way is to use the "Hide 
modules" feature which works in BibleTime only. These don't solve the 
problem, however, because novice users don't necessarily know about 
these. But as I said, in a multiuser environment where both the software 
and the modules are installed by an admin the user doesn't probably 
suppose to be able to remove the pre-existing modules. I think the home 
desktop systems are the problem if modules are installed without a 
novice user knowing it.

>> if someone installs a module with the package manager he knows how to
>> uninstall it properly.
> 
> Hopefully!  But his users may well not, if the UI they see presented by 
> a "module manager" in the app they use does not clearly distinguish 
> these modules from others a user may have installed personally and 
> per-user.  Hence the need for (at least) Possibility #1 above, IMO.

Which is reasonable, as I already commented.

> 
> Finally (for now): do the *.conf files for current modules provide an 
> indicator of whether a module will work if installed on a read-only 
> module location?  If not, should they perhaps include such info in 
> future?  Something like NeedsUserWriteableStorage=1 maybe?

I don't understand. The modules can be installed in any place anyways. 
Having writable content is a different thing than being able to 
install/remove a module - did you mean that?