Bug#868558: nmu: multiple r-* packages
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 | edd@debian.org
Reply to: