On 4 July 2016 at 18:26, Matthias Klose wrote: | On 04.07.2016 16:36, Dirk Eddelbuettel wrote: | > | > On 3 July 2016 at 18:01, Dirk Eddelbuettel wrote: | > | On Sun, Jul 03, 2016 at 07:43:49PM +0200, Martin Michlmayr wrote: | > | > [I've copied Matthias so he can comment on this] | > | > | > | > * Dirk Eddelbuettel <e...@debian.org> [2016-07-03 17:39]: | > | > > For this issue (and its already long thread in the BTS): | > | > > | > | > > - You are correct. We need g++-6 for QuantLib, for Rcpp and then RQuantLib | > | > > | > | > > - Shall I do new uploads of QuantLib (and then Rcpp) with g++-6 now? | > | > > | > | > > - To then be followed by a rebuild of RQuantLib? | > | > | > | > doko, can you suggest when to do this? If you read the bug log, | > | > you'll see that there are some dependency issues. | > | | > | Generally speaking, when R itself builds, it stores its CC,CXX,... settings in its | > | configuration which then becomes the default. | > | | > | So in that case I could rebiuld R itself with g++-6. I don't have much | > | experience "launching" a full binary migration in Debian but methinks | > | we need this here. And once R has been rebuild, we can just do | > | automatic (?) binary NMUs to get g++-6. | > | | > | (And for this particular bug I need to rebuild QuantLib as well.) | > | | > | Does that sound right? | > | > doko? | > | > Shall I start more narrowly with just Rcpp, QuantLib and then RQuantLib? | > This *will* force all package depending on Rcpp to rebuild: | > | > $ apt-cache rdepends r-cran-rcpp | > r-cran-rcpp | > Reverse Depends: | > r-cran-rcppeigen | > r-cran-rquantlib | > r-cran-xml2 | > r-cran-surveillance | > r-cran-shiny | > r-cran-rprotobuf | > r-cran-rncl | > r-cran-rinside | > r-cran-reshape2 | > r-cran-readxl | > r-cran-amelia | > r-cran-rcpparmadillo | > r-cran-plyr | > r-cran-minqa | > r-cran-htmltools | > r-cran-dplyr | > r-cran-bayesfactor | > $ | > | > I maintain some but not all of these. They *will* break when you mix | > compilers. | > | > Now, if we don't want that now, can we "defuse" (ie delay) the autoremove on | > rquantlib? | | hmm, but then you have to explicitly use gcc-6. Is this really something you | want to do? Why not wait until gcc points to 6, and then stage your transition?
Yes -- could not agree more. That is also what we did last round with gcc-5. So how do I get the autoremove on rquantlib turned off? Martin? Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | e...@debian.org
