[R-sig-Geo] rgdal: About the new gdal3 and proj >=6 condition

[Patrick Schratz]

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.

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?
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.
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.

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.
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.
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.

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.

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.

Best, Patrick
	[[alternative HTML version deleted]]