[Live-demo] Packaging and project re-organization

[James Klassen]

On 2013/12/31 4:18 PM, Alex Mandel wrote:
> Keep in mind that our installation method does double duty, not only
> installing an application but also as a guide for how to install such an
> application (I use the postgis script all the time for this). So
> inventing a new way to install applications that is not the norm for a
> known project needs to be easier and better than the current common method.
> 

This is the biggest hurdle I am facing with packaging GeoMoose as a .deb.

As GeoMoose is primarily HTML/JS and some PHP, there is nothing to
build.  There is some advantage to listing dependencies of the various
components in a .deb.  The demo app provides a working example of how
all these pieces (plus external dependencies such as MapServer and
Apache) can be used together with some example data.  My trouble is that
this is just one way the pieces can be used to build a whole.  For
example, using Nginx instead of Apache or using something other than
MapServer to serve WMS.

The demo is important to our users because many of them want to start
with something that works and incrementally substitute in their data.
Thus, the way people typically install GeoMoose is to install the demo
as a base (.zip or more ideally clone from GitHub) and start
configuring/customizing to their liking.  It is typical to have multiple
GeoMoose instances (possibly of differing versions) on one server.  The
install_geomoose.sh script as is does a good job of documenting general
steps someone could follow to install GeoMoose on any Un*x style machine
(assuming they can manually translate "apt-get install" to the local
package manager).  For the casual user, a .deb is much more opaque in
terms of understanding what is going on.