Thanks Johan,
There is a packaging column in our package spreadsheet here:
https://docs.google.com/spreadsheet/ccc?key=0Al9zh8DjmU_RdGIzd0VLLTBpQVJuNVlHMlBWSDhKLXc&usp=drive_web#gid=13
and and overview here:
http://lists.osgeo.org/pipermail/live-demo/2013-December/008540.html
+1 on the IRC sessions. We can also join Vienna code sprint in March
with a debian packaging session.
Best,
Angelos
On 12/26/2013 08:08 PM, Johan Van de Wauw wrote:
Angelos,
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.
Johan
On Mon, Dec 23, 2013 at 3:04 PM, Angelos Tzotsos <[email protected]> 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:
http://www.hiddentao.com/archives/2011/06/27/setting-up-a-simple-ubuntu-apt-repository/
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:
http://ubuntuforums.org/showthread.php?t=910717
but usually more complex things are required so the complete guides can be
found here:
https://wiki.debian.org/IntroDebianPackaging
http://www.debian.org/doc/manuals/maint-guide/
http://packaging.ubuntu.com/html/
2. Use helper programs to produce deb packages.
Recently I used this excellent tool for packaging/deployment:
https://github.com/jordansissel/fpm
https://github.com/jordansissel/fpm/wiki
http://goo.gl/sWs3Z
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
http://sourceforge.net/projects/geoserver/files/GeoServer/2.4.3/geoserver-2.4.3-war.zip
$ 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.
http://www.ansibleworks.com/docs/guide_vagrant.html
http://www.ansibleworks.com/docs/playbooks.html
Thoughts?
Cheers,
Angelos
--
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos
_______________________________________________
Live-demo mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/live-demo
http://live.osgeo.org
http://wiki.osgeo.org/wiki/Live_GIS_Disc
_______________________________________________
Live-demo mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/live-demo
http://live.osgeo.org
http://wiki.osgeo.org/wiki/Live_GIS_Disc
--
Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens
http://users.ntua.gr/tzotsos
_______________________________________________
Live-demo mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/live-demo
http://live.osgeo.org
http://wiki.osgeo.org/wiki/Live_GIS_Disc
