On Fri, 21 Feb 2020 at 13:13, Arun Isaac <[email protected]> wrote:
> >> > 2. a regression of r-rgdal introduced by your commit > >> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6 > >> > >> Replacing proj.4 with proj in the r-rgdal package seems to fix this > >> regression. Can you confirm? > > > > Maybe, but it is not what the user expects. Upstream explicitly > > mentions proj.4, see [1]. > > > [1] https://cloud.r-project.org/web/packages/rgdal/index.html > > No, upstream says that both proj (aka proj6) and proj.4 are > supported. Quoting [1], > > "From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..." I agree, but I was referring to "access to projection/transformation operations from the 'PROJ.4' library." or "Windows and Mac Intel OS X binaries (including 'GDAL', 'PROJ.4' and 'Expat') are provided on 'CRAN'." Well, your comment below says my remark here is irrelevant. :-) > > The question is: why proj instead of proj.4 in libgeotiff? > > The bug [1] cannot be solved using proj.4, why? > > proj and proj.4 are different versions of the same software, with proj > being the newer version. See > https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely > deprecate our proj.4 package and replace all occurrences of proj.4 with > proj. Thank you for the pointer, I was not aware. Well, I agree. Let replace all the dependencies of proj.4 by proj and deprecate our proj.4 package. --8<---------------cut here---------------start------------->8--- $ guix graph -t reverse-package proj.4 \ | grep label | cut -d'=' -f2 | cut -d',' -f1 "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" "[email protected]" --8<---------------cut here---------------end--------------->8--- Thanks, simon
