Emilio, Thanks for your follow-up. I will try to get to each point.
On 1 September 2017 at 11:42, Emilio Pozuelo Monfort wrote: | What Niels meant is whether having an old, non-rebuilt R module with the new | r-base works, Yes, in general, and here in this case. | and whether having a new, rebuilt R module with the old r-base Yes. (You get a warning when you run, say, R 3.3.3 and load a module built with R 3.4.1: "foo was built with R 3.4.1". But it is harmless. It still works.) | 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. I am. (20 year R user; package developer; contributor; R Foundation Board member) | >From your initial post, you say that the new R breaks loading optional code with | two of the available mechanisms. Allow me to repeat and stress: From R (< 3.4.0) to R (>= 3.4.0) the mechanism to use dynamically-loadable modules via .C() and .Fortran() changed, and requires a rebuild for the __subset of packages have loadable modules__ and the __subset of those packages actually using .C() and .Fortran() and not .Call()__ and the __subset of those package actually deploying the (before-than optional) registration mechanism. It is a subset of a subset of a subset that is affected, I identified the subset and asked the release team for 46 binNMUs. | That seems to imply that having a non-rebuilt module with the new R 3.4 would break (some things). Right? I do not think so. And I am not aware of a bug report anywhere (here in Debian or the wider R community) seeing it. This issue is not an ABI/API change. We very likely will get one of those in April with R 3.5.0. And as it stands, we'll all just wait for that. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
