Re: [be] Bibledit 4.0 packaged for Ubuntu - testing requested

[Jonathan Marsden]

Teus Benschop wrote:

> First of all: thanks for building the package! This will benefit a lot
> of people.

Good :)  Well, it will benefit people if it actually works well... hence 
my questions and the request for testing :)

> I there's anything you need to insert or change in bibledit's 
> documentation about this package, I've sent you an invitation with
> write permission on the Google Site for bibledit.

Got it, thanks, I'll take a look.

> I must admit that ssh is not used directly by bibledit. I have removed
> it from the build time checking, so this will be visible in the next
> release.
>
> ssh is mentioned in the online help:
>
> http://sites.google.com/site/bibledit/system/app/pages/search?q=ssh&scope=search-site
>
> The user may have to use it to set up a secure repository for
> collaboration on the Bible text Bibledit does not use it, but it does
> use, however, the secure version of git, and git in turn uses ssh.

Right, but such use is only at run time, not at build time, so logically 
the check should happen at run time not build time, shouldn't it? 
Perhaps the check should happen only the first time in a Bibledit 
session that a user tries do perform an operation that will need it.

I suppose I see this from a packager's viewpoint... to me, there are 
build requirements, and there are runtime requirements, and these may 
overlap, but they are often not exactly the same.  Documenting both 
kinds of dependency (and being clear about which is which!) helps both 
those compiling from a source tarball and those packaging the software.

> Bibledit's policy is to check at build time for any the binaries that
> ever could be needed. Any dependencies would be documented in the source
> of the build time checker, which is a file configure.ac in the root of
> the package. If these are covered, then it would be fine.

This works very well for build-time dependencies, I think this approach 
makes good sense for these.  It is logical, and well understood by 
people compiling software.  It is easy for someone compiling the code to 
see quickly what is missing, because configure tells them (just like it 
told me about SSH being needed, once I compiled BE in a minimal build 
environment instead of on my workstation!).  It might be nice to have a 
list of these in the README file, so that the person concerned can plan 
ahead a little and download them all before starting to try and compile 
Bibledit, but that's a "luxury", not an essential, and the HTML docs for 
each OS cover that kind of ground anyway.

However, I suspect that this (build-time only checking) approach works 
less well for anyone doing binary distribution, whether creating and 
distributing packaged binaries or just copying files around "by hand" so 
only one person has to actually compile the application.  In this case, 
run time checks are more useful, because they will "catch" more issues, 
and also because they can be more descriptive to the end user.  Indeed, 
they can even lead to modifying Bibledit behaviour dynamically to suit 
its (incomplete) environment, such as greying out BE menu items that 
will not work because some tool they need is missing, or (even better, 
perhaps?) popping up a message indicating exactly what tool is needed 
before this particular menu item will work.

> Bibledit version 4.0 does not yet use Apache or any other compatible web
> server.

OK, thanks for clarifying.  Sounds like my packages should actually 
work, then :)

> In version 4.1 the following will break when Apache is not there:
> - No references synchronisation between bibledit, xiphos, bibletime.
> - No collaboration possible between members of a team.


OK.  It seems unusual to require the use of a local web server for 
interprocess communication between collaborating applications (or 
processes) running on the same machine (on the same OS instance); there 
are other mechanisms for doing that, which seem to be more commonly used 
and which generally do not need the end user to set up and configure 
them by hand.  I'm sad that DBUS was apparently abandoned for this 
purpose; it really should be possible to make it work for this, but I am 
not nearly expert enough to become involved in details of that without 
doing many hours of work first!

For team collaboration, I can see the value in using a shared team web 
server, but I would have expected that would be something which is 
installed and configured just once per team, not once for each BE user 
or per BE workstation.  Then each copy of BE used by that team is 
configured to "know" the location (base URL) of the team web server.  Or 
maybe that base URL could be stored per project, in case one user is 
part of several teams -- but the point is that each user should not have 
to run their own web server to get this kind of team collaboration.  A 
ten person team needs one shared web server, not ten web servers!

> The dependency is not documented anywhere apart from in the
> installation documents online.

Once this dependency becomes "real", I would encourage you to document 
it somewhere in the source tarball (README file? INSTALL file?) so that 
someone who receives *only* the source tarball has all the information 
they need to build, configure and use Bibledit readily available to 
them.  Such a user will read the README and INSTALL files, but will 
probably not read all the HTML files, before building the application.

Jonathan