[Live-demo] Packaging and project re-organization
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...
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
$ 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
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.
Remote Sensing Laboratory
National Technical University of Athens
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Osgeolive