[Live-demo] [live-demo] Kick-starting OSGeoLive 7.5

Angelos Tzotsos gcpp.kalxas at gmail.com
Tue Dec 10 14:42:25 PST 2013


comments inline:

On 12/10/2013 11:56 PM, Alex Mandel wrote:
> On 12/10/2013 01:37 PM, Ivan Minčík wrote:
>> I would like to note a few things.
>> Creating and maintaining DEBs for all apps can be a huge task.
>> Theoretically, if it would be done, it needs to be re-maintained every time
>> when a new release is done (or does it make a sense to release without
>> updating apps ?). Updating packages at every OSGeoLive release means also
>> that it needs separate repository. This means another Debian GIS repository
>> fragmentation (Debian GIS, UbuntuGIS, QGIS Debian repo, others ...) and
>> less cooperation between projects. I think it is really important to join
>> forces of all Debian and Ubuntu GIS groups together [1] and make agreement
>> on rather less frequent but high quality common repositories.
At this point DebianGIS and UbuntuGIS cannot accept Java binaries to be 
transformed into deb. I know because I have similar issues with RPM 
systems. In RPM world the solution is to deploy a separate repository 
outside the distribution and create the files needed. Can we use a 
"non-free" repository from Debian/Ubuntu to upload deb files which are 
produced from war repackaging?

Just to clear things out: I AGREE that binaries should not be included 
in systems like Launchpad and OpenBuildService to keep control that a 
distribution can be built completely from source. Practical reasons for 
OSGeoLive dictate that we need packages from binaries though...
>> Personally, I think that maintaining high
>> quality repository (which means regular patching of security and other
>> important problems) is possible only for LTS releases.
> We should not be maintaining our own repo/ppa for anything that isn't
> specifically osgeo-live. That means only build scripts, documentation
> and data extractions are candidates. All 3 of these can happily live in
> the same repo/ppa. Software should always come from already existing
> sources as much as possible.
> I agree that we need to stick to every 6 months. It's things like QGIS,
> Geoserver, Leaflet, OpenLayers, geos, gdal, etc that are constantly
> changing and people always want the latest version (Note Geoserver is
> doing timed 6 mo releases). Long time stable software (I'm not going to
> call it Core because that will only lead to confusion) is already simply
> pulled from Ubuntu directly where it comes from Debian to begin with (ie
> GMT).
> As for Java packages, geonode/geoserver have demonstrated there is a way
> to still use ppa's even if the java source doesn't make it quite there
> at this time. We should not maintain our own debian style repo, thats
> way too much extra work when launchpad does it for us.
For GeoNode there are 2 packaging efforts: One is based on Jenkins and 
creates deb from GeoServer war (similar to what I propose above) and the 
second is ppa based and creates packages for python parts of GeoNode (it 
will work with a vanilla GeoServer running on 8080 but it does not 
include this in the deb)
> I think Angelos was thinking Docs/Translations needed to be split into
> it's own VCS. This is partly driven by wanting to use Transifex.
This is true, I would also prefer to move to git.

We could also use separate VCS for the rest: e.g. we could use a git 
repo to keep the debian files needed to create the deb packages. Perhaps 
this git repo can be the base for UbuntuGIS project too. Just a thought.
> The
> biggest downside is maintaining multiple versioning systems, which also
> could cause the docs/translation to be out of sync with the the actual
> releases unless we're careful to tag/branch specific to a release cycle
> and only pull the docs for that release.
This is something I am not scared of :)
Just see how KDE works....
> Just to be clear, the conversation appears to be conflating a package
> repository and version control repository.
> Thanks,
> Alex

Angelos Tzotsos
Remote Sensing Laboratory
National Technical University of Athens

More information about the Osgeolive mailing list