[Pkg-crosswire-devel] Module packaging, distribution, and management
refdoc at crosswire.org
Mon Jan 26 21:23:53 UTC 2009
Eeli Kaikkonen wrote:
> Jonathan Marsden wrote:
>> 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.
This would be a useful enhancement orrespective of the controversy on
package manager or not.
>> 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?
a) be indexed. This should happen for admin installed modules by admin.
b) user contributed modules (might) need write access. At the moment the
only serious implementation of this is in GS with its prayer lists and
in the personal commentary.
Otherwise write access is only used for installing/deleting modules.
More information about the Pkg-crosswire-devel