[Pkg-crosswire-devel] Module packaging, distribution, and management
Jonathan Marsden
jmarsden at fastmail.fm
Mon Jan 26 20:09:10 GMT 2009
Eeli Kaikkonen wrote:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
>
> It's possible that the Sword library has a bug in this respect. However,
> it doesn't mean that the package manager is the correct way to handle
> the modules, except in some special cases.
Thanks for this link. Now we have an official reference document to use
as a basis for our discussion.
It says in part:
Any program or package which contains or requires data that doesn't
need to be modified should store that data in /usr/share (or
/usr/local/share, if installed locally). It is recommended that a
subdirectory be used in /usr/share for this purpose.
Is the libsword package "a program or package which contains or requires
data that doesn't need to be modified"? I would say yes, it is. (It
may well contain or require other kinds of data that *does* require
modification, which would need to be installed in a user-writeable
location, of course!).
Are the sword-text-* packages "a program or package which contains or
requires data that doesn't need to be modified"? I would say yes, they are.
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.
It seems, then, that if a "module manager" is incompatible with this
standard and recommended approach, or how it presents things to the user
causes them difficulties that lead to support requests, then that module
manager has an issue that probably should be addressed. The primary
disagreement is apparently over how to address this issue.
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.
If the module managers need API support from libsword to do this, which
they probably do, then of course this is firstly a libsword development
issue. If not, then it is a front-end development issue. Doing this
adds utility on systems where there is no package management but there
are read-only network shared module data locations, for example -- this
kind of enhancement is clearly not only of benefit to Debian/Ubuntu.
Most likely, all that would be needed is a way to ask any given module
(or maybe, any given module data area?) "Are you writeable by me?".
That should be a very minimal API change, I would think. It is just a
single bit of info about a module the API can provide to the calling
application. There is no package management specific work here at all.
On top of this, we have package managers; many current operating system
distributions use some form of package management system to manage files
in system space, of course some implement them more consistently that
others or more thoroughly that others. While Possibility #1 improves
things somewhat for package-managed modules, it is still a less than
complete solution. This leads to:
Possibility #2:
If, in addition to #1, a "module manager" were able to recognize which
module storage areas were under package management control (whether the
manager is apt or RPM or PBI or some other management setup!) and (at
minimum) let the end user know, clearly, whenever they try to perform a
module management action that "undermines" the package management
system, then users would be even better informed, and so enabled to do
the right thing (use a package management tool to manage files that are
under package management control, basically!). This is a pretty low
level of package manager integration, but it adds considerably to module
manager end user understanding of what is going on.
At the API level this probably just needs #1, plus a "is this module
under system-wide package management control?" call (returning an
identifier for the package management system involved, and perhaps the
package name concerned, might a nice little enhancement, allowing for
clearer and more specific feedback to the end user -- but is not 100%
required).
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!
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.
>> However I also believe that from the admin's perspective, the various
>> programs should adhere to well-established principles like "the
>> program is not fundamentally incompatible with my distro's package
>> management system", with as few app-specific quirks as possible.
Amen!
> You have good points, but still I think the main problem has been that a
> random module has been installed without asking the user and it wasn't
> possible to uninstall it easily (because the user didn't know how it was
> installed).
Right; this aspect of the issue would be fully addressed by either of
Possibilities #2 and #3 above, and very partially addressed by #1 and #4.
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?
> 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.
> 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.
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?
Jonathan
More information about the Pkg-crosswire-devel
mailing list