Hi Charles, On 1 May 2017 at 14:53, Charles Plessy wrote: | Le Sat, Apr 29, 2017 at 09:50:01AM -0500, Dirk Eddelbuettel a écrit : | > | > I think I will cover these by hand now: | > | > package dotFortran dotC recommended | > 1: class-7.3-14 FALSE TRUE TRUE | > 2: cluster-2.0.6 TRUE TRUE TRUE | > 3: foreign-0.8.68 FALSE TRUE TRUE | > 4: KernSmooth-2.23-15 TRUE FALSE TRUE | > 5: MASS-7.3-47 FALSE TRUE TRUE | > 6: Matrix-1.2-10 FALSE TRUE TRUE | > 7: mgcv-1.8-17 FALSE TRUE TRUE | > 8: nlme-3.1.131 TRUE TRUE TRUE | > 9: nnet-7.3-12 FALSE TRUE TRUE | > 10: spatial-7.3-11 FALSE TRUE TRUE | > 11: survival-2.41-3 FALSE TRUE TRUE | > | > and we should binNMU the remaining ones satisfying | > | > binary: any (ie applicable for Debian binNMUs) | > has either .C() or .Fortran() | > | > I have access to a fully expanded directory of CRAN sources of if we start we | > the reverse depends I can refine the script above to get a set of packages | > for which we can then set up binNMUs. | > | > One caveat: the shell script does not (yet?) filter out those packages that | > already had a post R 3.3.3 update which includes eg several from the set above. | | Hi Dirk, | | this is very neat to pinpoint which package needs to be rebuilt. Related to
Let's recap: R Core told us in the release notes that with R 3.4.0, packages containing .C() or .Fortran() calls need rebuilds with R 3.4.0 (or its release candidate). Older builds will work for their R code, but not the compiled code; hence the rebuilds. This means the we have to find i) the subset of packages having compiled code and ii) among those having .C() / .Fortran and not .Call() and iii) those not yet having been rebuilt under R 3.4.0 (or its release candidate) And I have more / better code now, still based on the RcppAPT package (and its code on GitHub rather than CRAN). See the directory https://github.com/eddelbuettel/rcppapt/tree/master/inst/scripts/debian-packages In a nutshell, based on analysis I now ran twice, we - have 514 reverse dependencies of r-base-core in Debian - of which 487 match the '^r-' regexp suitable for package - of which 241 have themselves a reverse dependency on libc6, ie have src/ - of which 149 have not yet been rebuilt - of which 69 actually have .C() / .Fortran() calls For that last step I grep'ed actual sources (as I have shell access to a machine at CRAN central in Vienna which has all packages sources). The list of the 69 packages follows (as printed by data.table) package Package Version 1: r-cran-ade4 ade4 1.7-6 2: r-cran-adegenet adegenet 2.0.1 3: r-cran-adephylo adephylo 1.1-10 4: r-cran-amelia Amelia 1.7.4 5: r-cran-ape ape 4.1 6: r-cran-bayesm bayesm 3.0-2 7: r-cran-bitops bitops 1.0-6 8: r-cran-blockmodeling blockmodeling 0.1.8 9: r-cran-boolnet BoolNet 2.1.3 10: r-cran-brglm brglm 0.5-9 11: r-cran-caret caret 6.0-76 12: r-cran-catools caTools 1.17.1 13: r-cran-cmprsk cmprsk 2.2-7 14: r-cran-coin coin 1.2-0 15: r-cran-contfrac contfrac 1.1-10 16: r-cran-data.table data.table 1.10.4 17: r-cran-deal deal 1.2-37 18: r-cran-deldir deldir 0.1-14 19: r-cran-desolve deSolve 1.14 20: r-cran-dosefinding DoseFinding 0.9-15 21: r-cran-eco eco 3.1-7 22: r-cran-erm eRm 0.15-7 23: r-cran-etm etm 0.6-2 24: r-cran-evd evd 2.3-2 25: r-cran-expm expm 0.999-2 26: r-cran-fields fields 9.0 27: r-cran-gam gam 1.14-4 28: r-cran-genabel GenABEL 1.8-0 29: r-cran-glmnet glmnet 2.0-10 30: r-cran-goftest goftest 1.1-1 31: r-cran-gsl gsl 1.9-10.3 32: r-cran-haplo.stats haplo.stats 1.7.7 33: r-cran-hexbin hexbin 1.27.1 34: r-cran-igraph igraph 1.0.1 35: r-cran-lhs lhs 0.14 36: r-cran-logspline logspline 2.1.9 37: r-cran-mapproj mapproj 1.2-5 38: r-cran-maps maps 3.2.0 39: r-cran-maptools maptools 0.9-2 40: r-cran-mcmc mcmc 0.9-5 41: r-cran-mcmcpack MCMCpack 1.4-0 42: r-cran-mixtools mixtools 1.1.0 43: r-cran-mlbench mlbench 2.1-1 44: r-cran-mnp MNP 3.0-1 45: r-cran-msm msm 1.6.4 46: r-cran-ncdf4 ncdf4 1.16 47: r-cran-nnls nnls 1.4 48: r-cran-pbivnorm pbivnorm 0.6.0 49: r-cran-phangorn phangorn 2.2.0 50: r-cran-phylobase phylobase 0.8.4 51: r-cran-polycub polyCub 0.6.0 52: r-cran-princurve princurve 1.1-12 53: r-cran-pscl pscl 1.4.9 54: r-cran-qtl qtl 1.41-6 55: r-cran-randomfields RandomFields 3.1.50 56: r-cran-randomfieldsutils RandomFieldsUtils 0.3.25 57: r-cran-randomforest randomForest 4.6-12 58: r-cran-raschsampler RaschSampler 0.8-8 59: r-cran-rcurl RCurl 1.95-4.8 60: r-cran-sp sp 1.2-4 61: r-cran-spam spam 1.4-0 62: r-cran-spatstat spatstat 1.51-0 63: r-cran-spc spc 0.5.3 64: r-cran-spdep spdep 0.6-13 65: r-cran-surveillance surveillance 1.13.1 66: r-cran-tgp tgp 2.4-14 67: r-cran-tikzdevice tikzDevice 0.10-1 68: r-cran-vegan vegan 2.4-3 69: r-cran-vgam VGAM 1.0-3 package Package Version I'll be traveling to some workshops and conferences over the next two weeks so it will be harder for me to re-run this. But the code is generic, and I left comments in there. Anybody with access to Debian unstable and R can run this (having to install r-cran-rcpp and r-cran-data.table, and then having to install RcppAPT from source which is quick). | this I had one more reminder from a member of the Release team that r-base | should not be co-installable with the packages that it breaks. This is related | to the support of partial upgrades that I was mentioning earlier. | | At this point I see 3 options: | | - For each rebuild, insert a "Breaks" relationship in r-base's control file; | | - Increment r-api-3 to r-api-4 (or r-api-3.4, etc.) in order to not have to | maintain a long list of "Breaks" declarations. In that case, we have to | rebuild everything. | | - Just rebuild what has to be rebuilt, and do not support partial upgrades, | which is what has been done until now. I still think that is _perfectly_ adequate as it reduces _487 potential_ builds down to _69 actual_ ones. A few dozen binNMUs seems fine, a few hundred including hundreds of false positives less so. | Not supporting partial upgrades puts the maintainers of the r-cran and r-bioc | packages between the hammer and the anvil. This said, I think that we have | made constant progresses over the years, so I do not feel shy saying "not yet" | to the Release team again if needed. We can actually analyse this data and find the packages needing rebuilds, and that course of actions strikes me as the most appropriate one. Cheers, Dirk | Have a nice day, | | Charles | | -- | Charles Plessy | Debian Med packaging team, | http://www.debian.org/devel/debian-med | Tsurumi, Kanagawa, Japan -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
