Hi,
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.
+1
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.
+1
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
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
