Am Sonntag, 19. November 2017, 09:06:04 CET schrieb Dirk Eddelbuettel: > On 19 November 2017 at 19:02, Charles Plessy wrote: > | Le Sat, Nov 18, 2017 at 03:26:53PM -0800, Bill Harris a écrit : > | > Incidentally, you can see a bit more complete description at > | > https://unix.stackexchange.com/questions/402560/how-do-i-install-r-on-de > | > bian-stretch-given-the-r-api-3-issue . > | > | Hi Bill and everybody, > | > | if one installs R >= 3.4.2 from any source, then some Debian packages > | will be broken. The change of r-api virtual dependency prevents this to > | happen. > > Note that this was a transition forced upon the maintainer (ie me) by a > group consensus and override. I argued against it as the underlying issue > was rather minute [1] yet the imposition of the r-api change imposes this > "omg everything is borked" side effect I consider overkill. > > | Since you install R from CRAN's Debian packages, can't you also upgrade > | the r-cran-* packages using `apt-get install -t stretch-cran34` as > | suggested in > | <https://cran.r-project.org/bin/linux/debian/#debian-stretch-stable> ? > > In short, you need matching toolchains. For a given r-base-core package, you > need the corresponding r-cran-* > > Personally, I don't use these backports. My 'development' work happens where > Debian is fresh and new ("unstable", and "testing"); my deployments at work > and elsewhere happens to be on Ubuntu (different story). > > So I cannot speak to the state of these backports as that is a project by > Johannes outside of the official Debian scope. He may chime in.
Here I am: packages fixed in unstable by rebuilding against current R do not propagate to stretch and jessie or older Ubuntu distributions. Therefore, as the backport of R 3.4.2 to Ubuntu still provides r-api-3, I was under the impression that the 46 packages that you are listing in the current version of your document [1] must be broken in some way when using the current R backports on CRAN for Ubuntu. And I thought it is a good thing that they are not installable on Debian stretch/jessie when using the CRAN backport providing r-api-3.4. In order to check the relevance of this once again, I selected r-cran- data.table from your list. However, ironically, this package only uses .C() in a comment... So not really affected... My next try was MCMCpack. Grepping the sources I found lots of calls to .C(), e.g. in the function MCMChlogit(). me@box:~/tmp/r-cran-mcmcpack-1.4-0/R$ grep "\.C(" * ... MCMChlogit.R: Sample <- .C("cMCMChlogit", ... However, on Ubuntu Xenial using the backport of R 3.4.2 that still provides r- api-3, this function works beautifully (against my expectation). Finally, I tried deSolve as packaged in r-cran-desolve. It uses .C in all many of its major functions: me@box:~/tmp/r-cran-desolve-1.20/R$ grep "\.C(" * daspk.R: on.exit(.C("unlock_solver")) euler.R: on.exit(.C("unlock_solver")) iteration.R: on.exit(.C("unlock_solver")) lsoda.R: on.exit(.C("unlock_solver")) lsodar.R: on.exit(.C("unlock_solver")) lsode.R: on.exit(.C("unlock_solver")) ... But e.g. the function lsode() from the old r-cran-lsode package from Xenial (uploaded long before R 3.4.x) works nicely together with the R 3.4.2 backport. This leads me suspect that only calls to .C() (I didn't look at Fortran()) are affected that have the names of R objects as first argument, and not quoted strings like "unlock_solver". What got the whole issue rolling were the function coxph() in package survival [2] that uses internally a call coxres <- .C(Ccoxmart, as.integer(n), and the case that I found myself [3] involving the call z <- .C(lqs_fitlots, in package MASS. Therefore, in the light of the above, the list of Breaks: that I have pledged for [4] could have been even shorter than we thought. In fact, I am thinking about trying to produce such a shortened list for the backport of R 3.4.3 that is scheduled to be released end of this month, to be able to switch back to r-api-3 for the CRAN backports to stretch and jessie. Thoughts and/or helpful hands appreciated. I believe the best thing about all this is that we will all be prepared for the upcoming change of r-api-* next year. Cheers, Johannes > Dirk > > [1] http://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html [2] https://stat.ethz.ch/pipermail/r-sig-debian/2017-April/002680.html [3] https://stat.ethz.ch/pipermail/r-sig-debian/2017-April/002683.html [4] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=861333#95 _______________________________________________ R-SIG-Debian mailing list R-SIG-Debian@r-project.org https://stat.ethz.ch/mailman/listinfo/r-sig-debian