[Live-demo] Packaging and project re-organization

[Alex Mandel]

On 12/26/2013 01:27 PM, Ivan Minčík wrote:
>> 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.
>>
> 
> In current UbuntuGIS state I would propose creating Launchpad account for
> OSGeoLive and freeze rather DEBs there rather than using UbuntuGIS 'stable'.
> 
> 

We can just make an OSGeoLive repo as part of Ubuntugis or create an
OSGeoLive project page for separate PPA if we think it will count too
much against the quotas. Existing users should use their own accounts
(several of us are part of Ubuntugis already).

The biggest downside to this is that users don't have a direct upgrade
path. We would need to describe how to switch to the UbuntuGIS repo if
you want updates (ie for People who install, use persistent usb or
virtual machine).

This is actually a similar dilemma to the python packaging.

>> 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/
>>
>> This should be a task for Ubuntu or Debian or alternatively packaging
> projects like UbuntuGIS.
> 
> 
> 
>>
>> 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...
>>
> 
> For me FPM tool (os similar approach) looks as the only realistic way for
> projects like OSGeo Live. It provides very good ratio between price an
> result. I propose loading core GIS software like GEOS, GDAL, PROJ ... from
> packaging projects and all others from FPM. Even if I like using Python pis
> very much, I would propose using FPM also for all Python software to keep
> centralized approach.
> 
> Ivan
> 

Maybe we can try this on the pypi type stuff we need to keep up to date.
Are these compatible with upload to Launchpad?

We should avoid repackaging anything that is already packaged well. The
biggest downside of Ubuntugis is not enough people know how to update
the packages. If more people knew the right way to do this there would
not be a waiting game for newer versions to make it in.

As for the Java stuff, I think we should still kick this one down the
road and instead focus on packaging the docs and data into Ubuntugis
(specifically the OSGeoLive subrepo). We are not in a position to
maintain packages for projects, and while we can take some shortcuts to
improve the build process they should be easy for new people to work on
so introducing intricate packaging workflows doesn't fit.

FYI, there is an apt-get installable geoserver from the geonode team.
It's a wrapper around a bash script to download the war they want.

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.

Thanks,
Alex