On Mon, 01 Apr 2013 15:37:49 -0500, "Sebastian P. Luque" <[email protected]> wrote:
> On Mon, 1 Apr 2013 15:14:46 -0500, > Dirk Eddelbuettel <[email protected]> wrote: >> On 1 April 2013 at 14:12, Sebastian P. Luque wrote: >>> On Mon, 25 Mar 2013 18:51:24 -0500, >>> Dirk Eddelbuettel <[email protected]> wrote: >>> > On 26 March 2013 at 07:35, Charles Plessy wrote: >>> >> Le Mon, Mar 25, 2013 at 03:14:11PM -0500, Sebastian P. Luque a >>> écrit >> : > On Mon, 25 Mar 2013 13:14:15 -0500, >>> >> > Dirk Eddelbuettel <[email protected]> wrote: >>> >> > > c) If you must downgrade, I would downgrade to 2.15.3-2 from >>> CRAN >> > > rather than 2.15.1. >>> >> > Great, doing that right now. >>> >> Hi Sebastian and everybody, >>> >> Note (if it helps) that it is also available from >> >>> snapshot.debian.org. >>> >> http://snapshot.debian.org/package/r-base/ >>> > Ace -- thanks for the reminder about snapshot.d.o. >>> > As for Seb's query about mass-updates: what you do from ESS, I do >>> from > shell via littler -- and yes, I usually control via >>> lib.loc(). In this > case we may want to force it >>> everywhere... though I can't fully > recommend to overwrite files >>> owned by dpkg and apt-*. If it breaks, > you keep the pieces. >>> > And lastly, this is of course a bug in r-base as it could >>> potentially > conflict with its dependents. In practive, I don't see >>> how we could do > this easily so the best bet is probably to simply >>> upgrade the .deb > packages as fast as possible. >>> > Dirk >>> > My ~/bin/update.r is below, with some comments removed. A version >>> is > also in the littler sources and Debian package. >>> Thanks Dirk and Charles for the pointers. I'm now running a locally >>> installed R 2.15.3 and packages until the dust settles with 3.0.0. >>> I just noticed that many sid packages have now been rebuilt against >>> R 3.0.0. Kudos to Dirk and the team! However, I don't understand >>> how >> Yes, I kept busy over the weekend. >>> this works for packages that have an upstream Depends on R < 3.0.0. >>> One of these is nlme, and yet r-cran-nlme has been rebuilt against R >>> 3.0.0, even though it fails to load in this latest R with: >> I don't see that in the nlme sources. >> Rather, the one I uploaded (3.1-109) has >> Depends: graphics, stats, R (>= 3.0.0) R> library(nlme) >>> Error: package ‘nlme’ was built before R 3.0.0: please re-install it >>> What am I missing? >> I *very strongly* suspect that you have an older r-cran-nlme on your >> system, or that you have older nlme installation ahead of the current >> r-cran-nlme in your .libPaths() >> Check the result from installed.packages(). > Indeed, that was it! I somehow forgot to remove the temporary local > installations of nlme and coda, so they wouldn't be found before the > Debian packages. Sorry for the noise. > Again, thanks so much for keeping Debian so neat! This prompted me to write something to check for these things: ---<--------------------cut here---------------start------------------->--- local.lib <- .libPaths()[1] localpkgs <- installed.packages(lib.loc=local.lib)[, 1] ## The system-wide library: sys.lib <- .libPaths()[2] syspkgs <- installed.packages(lib.loc=sys.lib)[, 1] ## All the installed packages in local library that should be removed dups <- localpkgs %in% syspkgs ## Check them out localpkgs[dups] ## Remove them if (any(dups)) remove.packages(localpkgs[dups], lib=local.lib) ---<--------------------cut here---------------end--------------------->--- Assuming the default situation in Debian that .libPaths()[1] is the standard /usr/local/lib/R/site-library, where regular users can write. It also assumes of course one wants to remove all duplicate packages. If one has local R versions besides Debian, each using a library under say /usr/local/lib/R-VERSION/site-library, then one could have: R_LIBS_USER="/usr/local/lib/R-%V/site-library" in ~/.Renviron, then .libPaths()[1] would always correspond to the appropriate library, whatever local version of R is running. This is working neatly for me so far. Debian R ignores ~/.Renviron presumably because it has found /etc/R/Renviron first, so .libPaths()[1] is always the stock /usr/local/lib/R/site-library. Am I following this correctly? -- Seb _______________________________________________ R-SIG-Debian mailing list [email protected] https://stat.ethz.ch/mailman/listinfo/r-sig-debian
