[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [be] Bibledit 4.0 packaged for Ubuntu - testing requested
From: |
Jonathan Marsden |
Subject: |
Re: [be] Bibledit 4.0 packaged for Ubuntu - testing requested |
Date: |
Tue, 29 Dec 2009 18:48:19 -0800 |
User-agent: |
Thunderbird 2.0.0.23 (Windows/20090812) |
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