[R-sig-Geo] rgdal: libgdal requirements too restrictive

[Roger Bivand]

On Sun, 21 Apr 2013, Kirill Müller wrote:

> On 04/21/2013 08:31 PM, Roger Bivand wrote:
>> You could ask there what resources they would need to offer less antiquated 
>> packages for stable, which is your specific problem - testing and unstable 
>> are not up to date, but are not bad. The only practical solution is for 
>> Debian GIS to provide newer binary versions of GDAL and GEOS for Debian 
>> stable.
> If I understand Debian's release process [1] correctly, "stable" is 
> essentially what "testing" was two years ago, and not updated anymore except 
> for security bugs. So, unless I'm wrong on that point, the "stable" packages 
> are not going to be updated until the next major release of Debian. "Debian 
> GIS" doesn't provide packages for six years now, and neither libgdal nor 
> libgeos are available as backports [2] -- new packages compiled using the 
> "stable" toolchain. I cannot install from "testing" because this requires an 
> update of libc -- a bad thing to do in a production environment, I have been 
> told. And I'm not going to install from source, because this could mean that, 
> in the end, I'll have to reinstall everything that depends on those libs from 
> source.

The resource for R on Debian is:

http://cran.r-project.org/bin/linux/debian/

which describes how backporting is handled for R. Those needing 
rgdal/GDAL/etc. or rgeos/GEOS on Debian should sort out who is to do the 
work, and possibly approach R-sig-debian asking for advice. If those 
interested could secure the backporting of GDAL/etc. and GEOS, I think 
that it might be possible to ask the Debian R packages maintainer for 
assistance, but it is those backports that are the hindrance.

>
> While I understand that people write to you first when they see a bug in 
> rgeos/rgdal, I don't think that you can be held responsible for bugs in the 
> libs that those R packages wrap. If you insist on forcing people to use only 
> the most recent libgeos/libgdal, the ./configure script should reflect this. 
> Otherwise I find the dependency to 3.2.2 rather arbitrary.

This is GEOS 3.2.2, and relates to the use of the C API in rgeos:

http://trac.osgeo.org/geos/browser/tags/3.2.3/NEWS

Changes in 3.2.2
- Bug fixes:
   - CAPI: do not leak contexts when using the non-reentrant interface

and other bug fixes since 3.2.0. If you would like to change the condition 
in configure.ac, rebuild configure, and try out R CMD check (checking out 
rgeos from R-forge for convenience), we could relax from 3.2.2 to 3.2.0.

You could try the same approach with rgdal and GDAL 1.6.3 (multiple 
packages), PROJ.4 (multiple packages). Please see the rgdal README, also 
online at:

https://r-forge.r-project.org/scm/viewvc.php/pkg/inst/README?view=markup&revision=409&root=rgdal

This would avoid your having to install the external dependencies from 
source, but I cannot promise that it will be straightforward, as some 
examples may use drivers that entered GDAL/OGR after 1.6.3, and would then 
need to condition on driver availability. Between 1.6.3 and forthcoming 
1.10.0, lots of bugs have been fixed too.

Roger

>
> It's a difficult situation. I can ask the backports people if they can also 
> offer libgdal/libgeos plus whatever dependencies these packages have (PROJ.4, 
> ...). And of course there's always the way of "jailbreaking" rgdal/rgeos by 
> messing with its ./configure script -- implying loss of warranty :-)
>
>
> -Kirill
>
>
> [1] http://www.debian.org/releases/
> [2] http://backports.debian.org/
>

-- 
Roger Bivand
Department of Economics, NHH Norwegian School of Economics,
Helleveien 30, N-5045 Bergen, Norway.
voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no