[Live-demo] Fwd: Packaging and project re-organization
Johan Van de Wauw
johan.vandewauw at gmail.com
Thu Dec 26 10:08:46 PST 2013
I'm very much in favor. Well I actually made similar proposal before.
Do we have an overview of which packages are not yet packaged in .deb files?
Perhaps we can setup some IRC coaching sessions for people to get
started with packaging.
On Mon, Dec 23, 2013 at 3:04 PM, Angelos Tzotsos <gcpp.kalxas at gmail.com> wrote:
> 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 UbuntuGIS-Unstable.
> 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
> Live-demo mailing list
> Live-demo at lists.osgeo.org
More information about the Osgeolive