Hi Dirk, On 26/08/17 14:29, Dirk Eddelbuettel wrote: > > So I tried that -- and I cannot currently tickle the bug: > > -- r-cran-spatial (from the initial bug report) was long rebuilt by me > > -- r-cran-logspline (which you mentioned) is actually no longer on my > refined (shorter) list, no issues there > > -- r-cran-data.table (on my list) is a false positive, the one grep() > find is actually in commented-out code (but hey, the maintainer is a > slacker too as the package had two updates not reflected yet...) > > -- r-cran-rcurl just works too, there is one .C() call in getCurlInfo() > and it all passes as well. > > In short I can NOT currently reproduce the issue on Debian unstable. > > So this may be a huge nothingburger (and another reason not to enforce an > API-tag rebuild over 500+ packages).
What Niels meant is whether having an old, non-rebuilt R module with the new r-base works, and whether having a new, rebuilt R module with the old r-base works. Is that so? Sorry if you already answered this, but it's not clear to me and I'm not familiar with R at all so it's possible that I missed it. >From your initial post, you say that the new R breaks loading optional code >with two of the available mechanisms. That seems to imply that having a non-rebuilt module with the new R 3.4 would break (some things). Right? Thanks, Emilio
