rgdal: About the new gdal3 and proj >=6 condition
The URL returns a 404. FWIW I?ve tried it locally using the latest svn revision but have no clue where I should find `proj_api.h` (I?ve looked in the complete proj installation directory). I see ``` ls /usr/local/Cellar/proj/7.0.1/lib/ libproj.19.dylib libproj.a libproj.dylib@ libproj.la* pkgconfig/ ``` Even if this custom installation might work at some point, making such adjustments until gdal3 arrives in homebrew will be a major pain, also for CI builds. It would still be highly appreciated if this internal assertion would be removed again.
On 29 May 2020, at 18:37, Roger Bivand wrote:
I have put a tarball, built without vignettes with GDAL 2.2.4 and PROJ 7.0.1 that passes CMD check (with warnings for missing vignettes) on: http://spatial.nhh.no/R/rgdal/gdal_1.5-9.tar.gz It involves code copying to provide duplicated functions in three settings: PROJ < 6 & GDAL < 3 PROJ >= 6 & GDAL >= 3 PROJ >= 6 & GDAL < 3 (your homebrew case) You need the configure argument: --configure-args=--with-proj_api=proj_api.h. Without the argument, you now get directed to use it. For now I've dropped the configure tests for sqlite3, curl and tiff; works for me but may not work for you. Please make the output of: R CMD check --install-args="--configure-args=--with-proj_api=proj_api.h" rgdal_1.5-9.tar.gz available ASAP. I count on an immediate response. Roger On Fri, 29 May 2020, Roger Bivand wrote:
On Fri, 29 May 2020, Patrick Schratz wrote:
The just released rgdal v1.5.8 requires gdal >= 3 when proj >= 6 is present. It does not even install the package if this condition is not met but errors during linking.
Please document with the output of 00install.out from R CMD check rgdal_1.5-8.tar.gz, and pkg-config proj --modversion, gdalinfo --version with system details. Yes, PROJ >= 6 makes no sense without GDAL >= 3; GDAL 3 makes no sense with PROJ < 6. GDAL 3 with PROJ < 6 uses the old proj_api.h API and the old metadata structure with Proj4 string degradation; GDAL < 3 with PROJ
= 6 must use the deprecated API and the new metadata structure.
I could not find any sources in the web or in the announcement post of v1.5.8 why this condition was enforced so strictly. Does it cause unwanted results?
Yes, definitely. GDAL 3 was released as 3, not 2.5, to stress the
complete break between GDAL 2 (with PROJ <= 5) and GDAL >= 3 (with
PROJ >= 6) after GDAL barnraising. So:
PROJ
< 6 >= 6 GDAL < 3 OK NO
> = 3 NO OK
If so, then there is a big issue since the ?gdal2 and proj >= 6? combination has been used by many people in the past already.
No good precedent, just binary packagers protecting slow downstream adaptation.
I haven?t tracked down for how long this situation was on the
market
already.
Also the {sf} package is still installable with this combination
and I
am not aware of any warnings/issues that came up due to this so
far.
rgdal is a much older package and has much more older code that needs this protection. It is possible to accommodate the no-go areas, but I'd really value patches to R-forge, as I cannot check multiple PROJ/GDAL version combinations just because someone isn't up to speed.
It further causes complete breakage for people relying on the homebrew package manager on macOS since current versions are gdal v2.2.4 and proj 7.0.1.
They should never have gone beyond PROJ 5 if they are stuck on GDAL. PROJ 7 is a very different animal.
The update to gdal3 is blocked since months due to an incompatibility with `liblas` (https://github.com/libLAS/libLAS/issues/164). Reading the issue, it looks unclear when this issue will be resolved. The alternative osgeo4mac tap holds formula that is unstable and somewhat broken. One cannot link rgdal with the current gdal v3.0.1 from osgeo4mac. This incompatibility with homebrew-core formula leads to further issues for CI tests that rely on the spatial homebrew stack for macOS builds. All of this is really unfortunate and I am wondering if this was a known factor when introducing this condition in the new release. Unfortunately rgdal is not hosted on any Git* provider (there is just the CRAN mirror with not much information about the recent changes) and it is unclear/untransparent to me if there is a continuous integration setup at all for this package.
Do not require me to leave the excellent SVN service on R-forge. Provide patches there.
I hope this is not another case in the series ?I do not like operating system XY and hence I do not test on it? which was seen recently in another package. That?s what CI is for and the responsibility of package authors.
I run and develop on Fedora, I have no access to OSX, and the current release was fully checked with ~ 900 revdeps repeatedly since November on successive older and newer versions of PROJ and GDAL. I blocked new PROJ with old GDAL recently to simplify development. CI is only as good as the scripts, I am completely sure that repeated revdep testing and reading the output is superior.
Also one should be aware that not every rgdal user is member of this mailing list (I guess not even 5%) and many people in production will face this error during install, most of them without any clue what to do or an idea why this was raised.
There has been plenty of information given about the CRS changes. rgdal could simply have been abandoned by me, and all those production volunteers might have fixed things, but I never hear anything at all.
In summary it would be great if - There would be more detailed information on the introduction of the new condition - Awareness of state-of-the-art platform related library versions before making such a release - Transparency/Existence of a cross-platform build process - If the incompatibility is just due to some features not being accessible with this configuration, I suggest to raise a warning during package load but not prevent the package from installing in the first place - A version-based NEWS file would be available. Currently one only sees a revision-based Changelog: https://cran.r-project.org/web/packages/rgdal/ChangeLog I am well aware that I am indirectly criticising (hopefully in a constructive way) the transparency and release process here, for which I will probably get a rough response. However, if that leads to more robustness and transparency in future release, I am fine with this. A quick patch release resolving the breakage would be highly appreciated.
Only with community imput. what you ask is not needed, just extra complexity. Please provide patches, or accept my invitation to join the R-forge project and commit your fixes directly. I can see how to do it, but I don't think it makes sense, and your messsage has not motivated me, to be honest. I'm prioritizing working with CRAN to iron out reverse dependency problems. Roger
Best, Patrick [[alternative HTML version deleted]]
_______________________________________________ R-sig-Geo mailing list R-sig-Geo at r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-geo
-- Roger Bivand Department of Economics, Norwegian School of Economics, Helleveien 30, N-5045 Bergen, Norway. voice: +47 55 95 93 55; e-mail: Roger.Bivand at nhh.no https://orcid.org/0000-0003-2392-6140 https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en