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

[Jonathan Marsden]

Peter von Kaehne wrote:

>> (1) Your stated inability to see the utility of a single standard
>> packaging system suggests to me that you are more a part of a
>> Windows-oriented community that a Linux-oriented one.  Community norms
>> matter, and should be respected.

> I am using Linux (Debian and later Ubuntu since about 9 years as my only
> operating system). Personal assumptions should not be on this list.

What assumption?  Note carefully my use of "suggests to me".  That
remains an accurate statement; I may have received a wrong impression,
but the statement as written is not an assumption, personal or
otherwise.  In my own experience (which goes back to 1992 on Linux and
1980 or so on mainframes and minis, in case it matters), those who fight
against using package management schemes are often people coming from
environments where such tools are not available or not widely used.  I
simply stated what was suggested to me by your own earlier statements
(such as "I simply do not see the point").  Apparently you are an
exception to that.  Thanks for letting me know.

> The sole lack of respect shown here is by Debian towards

This sentence was incomplete.  Who or what is Debian not respecting, and
how?  And if the module manager does respect Debian package management,
it should already work fine with Debian-packaged Sword modules... right?
 Since it apparently does not, it must be trying to "do its own thing",
outside of or ignoring Debian package management entirely.  I submit
that acting in that way can very reasonably be construed as failing to
respect community norms (since the Ubuntu community normally uses
package management!).

> As soon as there is a dependency of any sort there will be increased
> support requests - "I do not want this or that bible and can not get rid
> of it!" we have them all the time and they solely come from
> Debian/Ubuntu users.

Use of Recommends: or Suggests: is preferable, of course; this current
issue with the "old" (existing) packages has already been discussed, and
reasonable solutions have been talked through in some detail already, I
think?  What you "have all the time" now is not necessarily what you
will get in future -- providing improved packages is what this team is
all about!  Let's work together to create them.

> I am assuming nothing. The module manager can install from any location,
> including CD's, USB sticks, network drives or whatever.

"From" anywhere... but not "to" anywhere?  What exactly is the issue it
has with modules placed by Debian packages into /usr/share/sword/, which
is a module location officially recommended by current Sword
documentation (see the INSTALL file from the sword-1.5.11 tarball)?
Either the Sword module manager does manage them fine there (without
workarounds such as someone changing perms by hand on files and
directories, of course!), or else there is an issue, and it does not in
fact manage them fine there.  I suspect the latter.

>>> It is not data like a game episode (a la Wesnoth).

>> Actually, I think this one is fairly close -- they contain information
>> in a non-standard data format, data without at least one set of which
>> the application is useless... this is a pretty good comparison, IMO!  In
>> what sense are Sword modules "not data"?

> This one is indeed the closest. But it still does not apply.

You make a statement here, without any supporting evidence or comment;
that is just a bare assertion, which is by definition not persuasive.
Are you willing to back up your assertion?  Or answer my earlier
question 'In what sense are Sword modules "not data"?' ?

> If the admin installs the modules then there is no difference between
> apt-get and module manager in accessibility

Really?  Is the admin really commonly running GnomeSword (for example)
as root?  On Ubuntu?  I would find that very surprising.

>> Good use of shared module install locations just makes sense in many
>> many situations.  Good use of data distribution on CD and DVD also makes
>> sense sometimes.  Debian/Ubuntu style package management handles both of
>> these, as well as the more common (in the West) case where individual
>> users have fast cheap Internet access available to them, and have at
>> least one PC per user.  Does your suggested approach do as well in each
>> of these situations?

> Yes it does. You can use a CD, usb stick whatever to install on a all 30
> PCs' on one central location if you run a server or whatever. The module
> mamanger will not install on /usr/share/sword only if it does not have
> the permissions. A competent administrator can sort this.

A competent administrator can install everything from source tarballs,
too!  But such an admin should not *have* to "sort this", if he has to
mess with directory perms my hand, then this suggests to me that the
tool he is using for package management is probably inadequate for the
task.  Competent sysadmins work with their package management system,
not against it. (BTW, I've been doing sysadmin/netadmin work in some
form on Internet-facing production servers running Linux and *BSD since
about 1994, so this statement comes from ~15 years sysadmin and netadmin
experience).

> As per default install via Debian these permissions are not there for
> ordinary users nor should they be there.

Right.  Are you now saying that the Sword module manager fixes them,
automatically, to your own idea of what they should be, when it needs
to?  I don't think so.  (Actually, I hope not!).  The admin has to go in
and tweak perms by hand for that to "work".  That is not something a
full function package management tool should need, surely.  Many admin
tools on Ubuntu prompt the user before using sudo when they need
elevated permissions to to package management and similar tasks; perhaps
this is how module manager could aproach this kind of thing, too?

> But your solution creates a problem for the single user on his own PC
> who installs ubuntu  on their onw PC and has suddenly two kinds of
> modules - module managers and apt-get installed ones - and does not have
> a clue how to deal with that situation.

Exactly!  So the logical long term solution is for *all* packages to use
and cooperate with the package management system that comes with the OS,
and which the user/admin is already using for other things on the
machine.  If we take that route, we either (i) remove the modue manager,
leaving package management to the existing tools, or (ii) the Sword
module manager needs to notice that it is running on Debian and use apt
libraries etc to do its work.  It would also notice RPM and use those
libs on Fedora/RHEL, etc.  I'm betting you would be unhappy with (i).
So that leaves (ii).

Actually, (ii) would be a really good solution, but it involves a fair
amount of work -- are you willing to work towards it?  We'd need to
start by specifying some enhancements to the current sword module
management API, get the spec approved, implement it, then put code into
front ends to use the newly enhanced API... it's doable, but for sure
not in time for Ubuntu Jaunty.  I suggest we look at that approach as
the long term way forward; it brings the Sword "module manager" more
into the Debian/Ubuntu world (and of course would do the same in the RPM
world, if appropriately specified and implemented).

> With ubuntu on the scene this is
> a serious problem. It creates a constant stream of requests on the
> mailing lists (and I have to deal with them, not you)

I think you may be confusing one current issue with an old set of Sword
packages, and the whole use of a package manager??  Single users on
their own Ubuntu PCs already use apt-managed packages (that is most
likely how they got hold of GnomeSword itself!) so they already can use
the existing package management tools, more or less by definition.  So
going in the opposite direction for one particular set of data packages
does not seem to me to be a rational response to the set of support
requests you are experiencing; getting the tool that does not currently
work well on Ubuntu (the Sword module manager) upgraded to work with
Ubuntu instead of against it would appear to be worth exploring.

>> I would like to read the full design documentation for the "elaborate"
>> module manager, including the set of use cases for it that were
>> considered before it was implemented.  Does such documentation exist,
>> and if so, is it publically available?  If so, please provide a URL to it.

> http://www.crosswire.org/pipermail/sword-devel/

Sorry, but I'm not going to read the entire archive of a mailing list to
weed out the design documentation for one part of its API; we have
weeks, not years, before the Ubuntu Jaunty deadline, and I'd rather be
doing packaging work for this team!  Can you provide a somewhat more
specific pointer, please?  Or are you saying that no such documentation
exists other than the source code?

Jonathan