[Ubuntu] Google Summer of Code for OSGeo-Live/UbuntuGIS/DebianGIS?

[Andreas Tille]

On Sun, Feb 09, 2014 at 08:52:26PM +0100, Johan Van de Wauw wrote:
> I think there are already many packaging guides out there, and if
> packaging guides are missing it should be up to debian/ubuntu soc
> projects to create them, I don't think this is something osgeo should
> do.

+1 (and see my hint to Debian GIS policy in my other mail)

> And in fact with dh, dh_make and a proper upstream (which is what
> matters) packaging really is very automated. The real problem is that
> upstream is often not 'proper´.

+1

> So ideally, we would have someone who can help pushing upstream to
> become 'proper'. I think this is a role osgeo can play. to give an
> example of what I mean see eg the comments I once made about mapguide:
> http://lists.osgeo.org/pipermail/ubuntu/2010-April/000190.html
> Eg for java packages he/she could first start by listing which
> dependencies there are. If dependencies are on specific versions he
> should try to find out whether this is really necessary and advise the
> projects to do things differently.

+1

> I'd also be looking at the future,
> working on the latest git/svn versions of packages rather than trying
> to build the released versions, so changes are picked up in the new
> versions rather than seperately in eg debian gis.

I admit I'm to uneducated in GIS software and also the scope of osgeo to
have a valuable opinion on this.  When wearing my Debian maintainers hut
I'd prefer released versions over code drained from VCS but it might be
useful for you.  I just want to say that even if you are packaging "in
advance" of Debian you could use the Debian GIS packaging repository as
well when using proper version names and branches.  I think this should
be discussed with Debian GIS team and yould be for profit of both sides.

> If people now say that some java packages are hard to package properly
> on debian it is partly because we don't have a list of all the issues
> and nobody who really had time to compile such a list.

+1

> Once such a
> list is made different people with different skills can act on them.
> Somebody in debian may have easy solutions for some issues, while some
> things may be easy to fix for upstream if they realize that something
> is a problem.

I fully agree.

Kind regards

      Andreas.

-- 
http://fam-tille.de