[Live-demo] Sahana Install - minor edits

[Brian Hamlin]

Hamish, thank you for your considered response..
and your good work on these scripts..

after talking it out with knowledgeable colleagues
I think a)  we should do little to this release, so it gets out the door
and b) one possible solution is
   since all these sub-scripts are run by a master script.
have the master script define a couple of good vars
and standardize on having all the sub-scripts use them

  hth
    -Brian


On Feb 14, 2011, at 1:42 AM, Hamish wrote:

> 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/.

In the tiny bit of this kind of scripting
>
> 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
>
>
>
>
>