[R-sig-Debian] Debian backport on Stretch?

[Johannes Ranke]

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