[Live-demo] Sahana Install - minor edits

[Hamish]

Brian wrote:
> I have a raw, base XUbuntu that I build from..
> I selectively run and delete components on it the `pwd`
> approach broke for me probably based on whether the current
> directory was the base of the svn checkout or in its child
> directory, bin, at a particular time

scripts expect to be run from the bin/ dir, or the relative
path names will break. previously scripts would use 'svn co'
to download app-conf/ files but that was ridiculous as they
were already part of the svn tree, so it was changed to relative
path names as ../app-conf/.

you are right that being able to run the script from anywhere
makes it more portable in one way, but having the gisvm/ dir
in $USER_HOME AND the entire svn checkout done in the boostrap.sh
step is a much higher burden than just needing to have the svn
checkout somewhere and not having run bootstrap.sh and needing
$USER in place before you can run any of the scripts. So in that
way it is less portable than the self-contained ../relative path
method.

we are both "right" in a way, but the choice is either a) need
to run boostrap.sh and set up our custom build tree first, but
from anywhere, b) need to run from the ./bin/ dir, or c) go back
to svn checkouts for the support files allowing both a) and b).

(I think option (c) is nuts seeing that we already have the file)

option (b) is the simplest, and does not make the build's child a
dependency of the parent-build (mixing/entangling those is just
asking for trouble), and so it is what I migrated everything to
a year or two back.


> Literally, since $BUILD_DIR is a *variable* it can be defined
> to *something else* by a moderately knowledgeable user
> and then the rest of the script may work, yes?

Not quite, I made it a variable to be a placeholder, as "cd -"
only gets you back to the previous pwd, but someone might easily
add another "cd" in the script without noticing it was depending
on that. If shell scripts allowed to define variables as "const"
or as #define, this would be a candidate for that. But all we
have to work with is $VARIABLE. Returning to the original ./bin/
$BUILD_DIR was needed so you could get back to that original
./bin/ dir where there script was meant to be running from and
still have the ../relative paths work. "relative" being the
important word there- the svn checkout should work from anywhere
without extra dependencies (booststrap.sh being run previously,
or svn tree happening to be linked in $USER_HOME for example of
a very big pre-dependency)


> Many scripts do use $USER_HOME/gisvm as the base directory
> from which to reference other svn based resources

which ones?  try:
  livedvd/gisvm/trunk/bin$ grep 'BUILD_DIR=' *.sh
  livedvd/gisvm/trunk/bin$ grep '$USER_HOME/gisvm' *

- install_desktop.sh is allowed to use $USER_HOME as it's part
of the ISO building task.

- geoserver, mapserver, and otb installers are wrong to write
data/doc files directly to the $HOME directory. They should
write to /usr/local/share/data/ or similar and symlink into the
home dir from there. remember that anything written to $HOME
will have to be held in RAM at runtime, so we try to keep that
to a bare-minimum.

other than that it's just sahana and tomcat, which are due to
your edits in the last few days.


and for what it's worth:
  livedvd/gisvm/trunk/bin$ svn blame *.sh | grep 'BUILD_DIR='


> Its unambiguous, for this disk layout.
> That sequence is stable in the current build

but non-existent outside of our little build setup.. the idea
is that as much as possible (if not 100%) only the script itself
and perhaps it's app-conf/ dir be needed. (+ perhaps bits of
setup.sh too, to ensure basic wget, gcc, make and friends)

> I dont think that the scripting is far enough along to have
> defined some ideal set of shell variables and current working
> directories, to generalize execution from within the build as
> it is now,

They are that definitely that far along, because that's exactly
how I designed it and have been quietly shepherding the ones not
directly written by me as we've gone along.

> and externally in the abstract

A *lot* a hard work has been put in to keep the build structure
clean so that sort of thing would be easy to do. I don't claim
everything is perfectly in-line and solved, but it is (or at
least was) very consistent with a reasonably well thought out
structure. I audit almost every line of every commit to the bin/
dir (and have done since the first commit) for a reason.


> If you, Hamish, have a vision for an overarching, self-
> consistant set of shell vars and working directories such that
> svn resources can be referred to from the build script on and
> off the LiveDVD build, by definition of a cooperative software
> project, you are invited to define and even build that vision,
> for all install scripts

well the thing is I've already done that and implemented that!

& from the start, even if I haven't elucidated or explained it
very well (if at all outside of the commit log messages), which
is probably the real problem here.


Expecting to have the scripts run from within the ./bin/ dir
is by design, and means we don't need a $GISVM_SVN_HOME variable
set or slow 'svn checkout's for files we already have downloaded.
I think I'm beginning to repeat myself much.. but want to take
the time to explain the reasoning clearly instead of just some
heavy handed revert in svn without explanation.

so I only pointed out this change out because diverging from the
[albeit unstated] consistent design makes it -not wrong-, just
"less than ideal", as it was actively designed to be self-
contained/dependent at the checkout level and depending on the
actions of bootstrap.sh and child-level files breaks that.



hope that makes sense,
Hamish