Bug#868558: nmu: multiple r-* packages
On 01/09/17 14:28, Dirk Eddelbuettel wrote:
>
> On 1 September 2017 at 13:52, Emilio Pozuelo Monfort wrote:
> | On 01/09/17 13:25, Dirk Eddelbuettel wrote:
> | >
> | > 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.
> |
> | Then I don't understand why these binNMUs are needed.
> |
> | >From #861333 OP:
> |
> | "With current R, R packages built for Debian before the upload of R
> | 3.3.3.20170413-1
> | on 14 April that use .C or .Fortran do no work properly, because the functions
> | calling .C or .Fortran do not find the compiled objects."
> |
> | That tells me that if you upgrade R but don't upgrade some modules, those will
> | (partially) break. Hence we need either an ABI bump, or versioned breaks against
> | the affected modules in r-base.
>
> The Bug:
>
> - package foo contains .C() or .Fortran and registers it
> - it is built with R 3.3.* (or any R before R 3.4.0)
> - you upgrade to R 3.4.0 tries to load that function in foo
>
> Not a bug:
>
> - any other use case including staying at R 3.3.3 and using
> a package from R 3.4.0 (not that you could with Debian because all
> r-cran-* packages already impose a >= on the R that built it).
The problem is that you can end up with r-bioc-makecdfenv_1.50.0-1 (i.e. before
the rebuild) and r-base_3.4.1-2, because nothing prevents that combination.
Emilio
Reply to: