[Live-demo] Packaging and project re-organization

Angelos Tzotsos gcpp.kalxas at gmail.com
Mon Dec 23 06:04:29 PST 2013

On 12/10/2013 10:52 PM, Angelos Tzotsos wrote:
> My proposal here is to split the project (since it grew too big):
> - OSGeoLive ppa (UbuntuGIS or perhaps other)
> - OSGeoLive apt repository (for packages not fitting under the 
> Launchpad rules, eg. Java binary packages)
> - OSGeoLive docs and translations (should be maintained separately and 
> create a deb file periodically e.g. for every new commit)
> - OSGeoLive data (also should be packaged in a deb file)
> - OSGeoLive build scripts (for anything not in a deb file, e.g. the 
> actual build files)
> This would also simplify things:
> All projects must provide deb packages, else they are not included in 
> the 8.0 release. So 7.9 will be a transition release...

Hi all,

Based on the previous proposal I would to discuss the potential 
solutions on how to create Debian packages targeting the 8.0 release:

My suggestion here is to create a Launchpad account for OSGeoLive, which 
we will use to "freeze" UbuntuGIS-Unstable when we are preparing a 
release. This means that this OSGeoLive ppa will not be used for 
packaging, just for release purposes, to avoid last minute changes in 
Alternatively we could use UbuntuGIS-Stable and try to keep the packages 
we need there, but this would require the OSGeoLive team to have a 
certain level of control to that ppa which I am not sure it is proper.

The second step is to make sure we have a place to host deb files that 
are not acceptable under the Launchpad rules. A simple solution would be 
to create an apt-repository to the OSGeo infrastructure. We just need a 
folder under apache and ssh access so that we can periodically upload 
deb files and re-calculate the index:

The third and "difficult" part is the deb packaging itself. Here we have 
several possible paths:

1. Use all the standard tools in Debian packaging and create/update 
packages on UbuntuGIS ppa.
A VERY simple example to create a deb package is shown here:
but usually more complex things are required so the complete guides can 
be found here:

2. Use helper programs to produce deb packages.
Recently I used this excellent tool for packaging/deployment:

This actually can save us lots of trouble, especially for building 
things that cannot easily be moved to Launchpad.

Small example to create a GeoServer package:
$ cd /tmp
$ wget 
$ unzip geoserver-2.4.3-war.zip
$ mkdir -p /tmp/geoserver-root/var/lib/tomcat6/webapps
$ mv geoserver.war /tmp/geoserver-root/var/lib/tomcat6/webapps/
$ fpm -s dir -t deb -v 2.4.3 -n geoserver -a all -d tomcat6 -C 
/tmp/geoserver-root .

and we have a geoserver_2.4.3_all.deb file ready for us. This also 
declares tomcat6 as a dependency and will just deploy the war file in 
the correct tomcat folder.

Then we upload this to our OSGeo apt repository (since we cannot upload 
Java binaries to Launchpad) and we simple change the 
install_geoserver.sh to apt-get install geoserver. OK, it is a bit more 
complicated than this, but you get the picture :)

FPM also supports translation of Ruby gems and Python packages into any 
other format... so it is easy to create deb packages from pypi...

This can also be combined with Ansible and Vagrant to automate every 
step of the build process.



Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/osgeolive/attachments/20131223/733a0abf/attachment.html>

More information about the Osgeolive mailing list