[Pkg-crosswire-devel] On 1.5.12 and our own Debian package repo

[Jonathan Marsden]

Matthew Talbert wrote:

> Another frontend, BPBible, has released their own bugfix 1.5.12
> version. ...

Aha, so we're re-hashing an idea that has already been (somewhat)
implemented!  OK.  Questions:

(a) How can someone in good conscience call this 1.5.12, since 1.5.12
has not been released yet?  Is this a group of coders with prophetic
gifts???  No-one on earth knows precisely what other new stuff will find
its way into the real official SWORD 1.5.12 in "a few months".  So, that
tarball should probably be labelled based on the fact that it came from
SWORD svn, and the date it was extracted from there, so
sword-1.5.11.svn20090402.tar.gz might be OK.  This tells the user
exactly what they are getting, up front.  Calling this file 1.5.12 is,
in my view, misleading and should be strongly discouraged.

> Due to some other shortcomings of sword on Windows, we are
> already using a heavily patched version as it is. You can get this
> version here: http://code.google.com/p/bpbible/downloads/list.

(b) What exactly *is* this code?  I grabbed
http://bpbible.googlecode.com/files/sword-1.5.12.tar.gz which looks like
the right kind of file... but it has *no* indications in it that I can
find that it is an unofficial modification of the original.  INSTALL,
README etc files are all unchanged.  Surely this is an unhelpful
approach to be taking -- at minimum one should document what was changed
and why, and specifically where the original came from (what revision of
what branch of what svn repository)...

(c) How exactly does the file
http://bpbible.googlecode.com/files/sword.patch relate to this tarball,
if at all? It's name is too generic to be really informative, IMO.
sword-1.5.11-fix-for-unicode-filenames.patch might be great (if that is
what the patchset does!).

> The only other issue is to create some method to "fix" the personal
> commentaries that were created before the patch. I don't understand it
> nearly enough to know how to go about doing that.

On 64bit Ubuntu I cannot create a Personal commentary using 1.5.11, or
at least, not very usefully -- I can create one, but I can never edit a
comment I have made on a given verse!  The edited comment ends up in a
file whose name is \r\n (carriage return line feed, hex 0x0D 0x0A) and
which is not visible to or used by the application.

Unless this is already fixed, or the issue is unique to my system
somehow, worrying about converting old 32bit commentaries to 64bit ones
seems premature to me... new installations on a 64bit OS are simply
broken in this regard, as far as I can tell, under SWORD 1.5.11.  This
is a very user-visible bug, and it could be somewhat distressing if a
user types in a lengthy comment edit or three and saves them, and only
later discovers they "did not save".  It's like a word processor that
doesn't really save your carefully edited document!

The way forward:

The apparent total lack of documentation for both the tarball and the
patch file makes me extremely wary of using either of them... hopefully
this can be remedied?  Who would we ask about that?

For example, if the tarball included the a shell script that goes out to
the svn repo and grabs the code so as to pick up exactly what this
tarball uses, for example, and a README (README.tarball?  README.first?
 whatever!) that explains how and why the tarball was created, and which
library bugs it is intended to address, that would  be extremely helpful
documentation to have included.

Lastly: The very fact that packagers and front end developers are
finding it necessary to do this kind of thing at all should be a very
loud wake-up call to the SWORD team that something is badly wrong here.
 Sorry if that is overly blunt, but clearly the needs of the developer
community who are their primary "customers" are not being met by what
they are releasing, or this sort of thing simply would not be happening.

Jonathan