On 27 April 2017 at 15:45, Johannes Ranke wrote: | Package: r-base | Version: 3.4.0-1 | Severity: normal | | With current R, R packages built for Debian before the upload of R | 3.3.3.20170413-1 | on 14 April that use .C or .Fortran do no work properly, because the functions | calling .C or .Fortran do not find the compiled objects. | | Example packages are r-cran-spatial and r-cran-kernsmooth. | | An example session in a fresh Debian sid chroot: | | > library(spatial) | > example(surf.gls) | | srf.gl> library(MASS) # for eqscplot | | srf.gl> data(topo, package="MASS") | | srf.gl> topo.kr <- surf.gls(2, expcov, topo, d=0.7) | Error in surf.gls(2, expcov, topo, d = 0.7) : object 'VR_frset' not found | | | The relevant NEWS entry from R is | | * Packages which register native routines for .C or .Fortran need | to be re-installed for this version (unless installed with | R-devel SVN revision r72375 or later).
To a very first approximation, just over 1/4 of all CRAN packages contain compiled code. The ratio will be higher for the r-cran-* subset as we skew towards bigger / more well-known packages. Per the script I posted to r-sig-debian about 1/3 of packages still use the .C() and .Fortran() interfaces to compiled code (rather than the now-recommended .Call(). | Packages compiled locally can simply be rebuilt using | | update.packages(lib.loc="/usr/local/lib/R/site-library", checkBuilt=TRUE) | | However the packages provided by Debian packages are installed in a directory | only writable by privileged users. That's irrelevant. You also need to be "privileged" to install a .deb package. What is more relevant is that the /usr/local/lib/R/site-library path comes before the package path -- so any user can always 'shadow' a potentially borked package with a local installation from CRAN (which may be more current too). That is a feature. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
