[R-sig-Debian] checking for duplicate packages (was: downgrading to R 2.15.1-4 from sid beta 3.0.0)

[Sebastian P. Luque]

On Mon, 01 Apr 2013 15:37:49 -0500,
"Sebastian P. Luque" <spluque at gmail.com> wrote:

> On Mon, 1 Apr 2013 15:14:46 -0500,
> Dirk Eddelbuettel <edd at debian.org> wrote:

>> On 1 April 2013 at 14:12, Sebastian P. Luque wrote:
>>> On Mon, 25 Mar 2013 18:51:24 -0500,
>>> Dirk Eddelbuettel <edd at debian.org> 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 <edd at debian.org> 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