[sword-devel] Module managers on multi-user systems, and related packaging issues

[Jonathan Marsden]

Refdoc wrote:

> The module manager has two defaults as long as it has writing permission
> - /usr/share/sword for all user installs and .sword/ for private installs.

That is surely an oversimplification?  It should be reading the Sword
config files and managing all modules in all of the many locations it
finds among them.  The Sword library specifies those config files and
how to interpret them; the module manager should not be making any
assumptions about what paths the config file(s) contain.

BTW, making the module manager a separate application (or two, one GUI
and one command line?) that is callable from the bible viewing/reading
apps, might be well worth considering -- otherwise each reader app needs
to re-invent the module manager wheel, which is clearly inefficient.
Has your development team rejected this more modular approach for some
good (and ideally documented!) reason?

> But irrespective of thus the problem which comes about in Ubuntu or
> Debian is following:
> 
> modules installed via synaptic are bypassing teh module manager and get
> installed in a location where the module manager has per standard
> configuration no write pribvileges - so he can not uninstall modules -
> despite being invited to do so by the module manager.

I suggest that the manager should not invite a user to do something it
cannot do -- this is a module manager bug, not a packaging problem, as I
see it.  You should file a bug report against the module manager to get
this fixed :)

> The other problem is: In the ubuntu repositories are a large bundle of
> modules which are all listed as dependencies of libsword. They are
> fulfilling the dependency all equally, but are called alphabetically.

That can (and probably should) be changed so that the default one picked
to satisfy the dependency is a common freely redistributable English
bible; that's not a huge deal, I am pretty sure I can help make that
happen, if we get to the point of updated packages that meet Debian
packaging standards.

> So, the preferred solution is to remove a) the dependency and b)
> preferably remove the sword modules altogether.

I'm not sure that's appropriate; I would change the dependency to
provide a commonly used default bible module to meed the dependency --
but I am not a serious expert in this stuff, once we get going a bit
more I can ask appropriate questions on #ubuntu-motu of others with more
experience than I have in this area.

> It does most of these things (not the authentication - see above). But
> the synaptic install bypasses this and creates a situation where the
> module manager does not work as designed.

Are there design docs for the module manager available?  Link please!
My sense is that much of this issue is actually caused by some
relatively poor (possibly Windows-oriented) design choices for the
module manager.  I'd like to read the design docs to see if they change
my mind -- or strengthen it (!) on that point.

> We do not have any official packages. Dominique Corbex "DomCox" (one of
> the GS developers) maintains a repository at:
> 
> http://dominique.corbex.net/gnomesword/

Thanks; I suggest that you should at minimum consider linking to that
repo from your Software page so that this is easily visible to Debian
and Ubuntu users reading your web site?

> They are generally good and install cleanly on a new system. I have
> obviously no clue how much they conform or not to Debian's and Ubuntu's
> rules.

That's the rub; creating your own local packages that "work" is
different from creating packages acceptable to the official
distribution, whether for Debian, Ubuntu or Fedora (or FreeBSD).  There
is a tool called lintian that any Debian/Ubuntu packager can use to
check both source and binary packages for many packaging issues; getting
packages "lintian-clean" is a significant first step in getting them
ready for official acceptance into Debian or Ubuntu.

> The RPMs are produced by someone else and tend to go in straight to
> Fedora with minimal latency, so there was never any pressure to have
> official packages for that.

Interesting; these too are not visible on the CrossWire site, and you'd
get increased visibility for your work if they were included in a major
Fedora repository, and perhaps later in SuSe and other RPM-based distro
repositories too.  If CrossWire is going to start "doing packaging
right", then my suggestion would be to think (long term) about getting
your software into as many Linux and *BSD distributions as you can :)

> Debian (and Ubuntu was good enough until about a year

OK, it sounds like you lost an active maintainer and things went slowly
downhill.  If we can get a decent packaging team together we can reverse
that.  Getting fully up to speed may take a few months though.

Jonathan