(Removed Kurt now, no need to fill his inbox; this will get archived at the Debian BTS.)
On 19 December 2018 at 08:22, Emmanuel Charpentier wrote: | Dear Dirk, | | the brute-force appears to be effective for R 3.5.1. | | Le mardi 18 décembre 2018 à 15:37 -0600, Dirk Eddelbuettel a écrit : | | [ Snip... ] | | | > > It's more complicated than that. reinstalling rstan, or even Rcpp | > > the | > > rstan, isn't sufficient to install brms. | > | > There are more C++ parts than rstan and Rcpp. I would try to | > reinstall them. | | Finding them all is not trivial : one may (recursively) find brms's | ancestors, but finding the C++ parts is not. | | Furthermore, the search for a package's ancestors is not, as far as I | know, in an existing package. It should be written and debugged. To my Have a look at https://eddelbuettel.github.io/rcppapt/binnmuAfterR340.html which is squarely in that problem space accessing the Debian package info from R allowing you to combine the R package info with it. | (limited) abilities, the brute force approach is faster in terms of | human time (a couple minutes at most). The (impressive) machine time is | less of a concern : I happen to have other fish to fry (e. g. | biological/psychological necessities shch as sleeping)... | | > > You did the right thing to file it here: | > https://github.com/paul-buerkner/brms/issues/573 | > Until we know more it should stay there. | | This issue has been annotated to point to the present bug. Do we need the same issue reported twice? | > BTW there you write 'running as root' -- don't do that. I added | > myself to | > group staff as it is the group on /usr/local/lib/R/site-library. Now | > I can | > (and do) runn eg littler's 'install.r' as me. Been doing that for | > years. | | Good idea. I didn't know that group belonging was enough for this. Is | that true also for routine Debian package management ? No, that is different. And what allow this for is standard Unix permissions as they were designed. No magic. | > To sum up, if a binary is in Debian itself chances are it gets | > updated when | > it needs to. | | Modulo some Debian delay, which might be not inconsiderable (consider | emacs... and don't get me started on ELPA packages...). It's complicated. I maintain r-cran-* packages, but all I use is in /usr/local/lib/R/site-library because I want to control the upgrade speed (daily, mostly). I do the same for ELPA packages now and it also works (though is less optimally applicable only to me as it installs in below $HOME). | > When we install "outside of the distro package manager" directly | > from CRAN things like this can happen. Maybe it was glibc. Maybe it | > was a | > change in g++. Maybe it was something else. Paul was correct in | > pointing to | > CRAN and the positive test results there. When nothing changes the | > package | > remains happy... | | Some "interesting" R packages are not in Debian packaging of CRAN (some | aren't even on CRAN : I had to install some of them in order to | collaborate with Paul Buekner on a paper). So out-of-Debian may be a | (regrettable) necessity... There are lots. You could always volunteer to maintain them. Someone has to sit down and do the work. Or else we install from CRAN. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
