Skip to content

levelplot

3 messages · Deepayan Sarkar, Dirk Eddelbuettel

#
It's in a special directory (because it's not compatible with R 2.2) that
update.packages doesn't know about (I think).
Sounds like the proper way to go, so I'm CC-ing.

I realise that this is a tricky situation: there are multiple copies of
recommended packages, one set that goes with an R release and another that
gets updated more or less independently. I'm not sure what the best
strategy would be from the Debian packaging perspective (perhaps looking
in both places and choosing the one with higher version number but still
compatible with the corresponding R version).

Deepayan
#
On 18 April 2006 at 16:23, deepayan at cs.wisc.edu wrote:
| 
| > I'm running debian unstable, and have been happy with the packages
| > that Dirk provides for unstable so far. update.packages() doesn't seem to
| > update lattice to 0.13.
| 
| It's in a special directory (because it's not compatible with R 2.2) that
| update.packages doesn't know about (I think).

Ahh. And while Dirk checks daily, he only checks in $CRAN/src/contrib and
doesn't see it there.  And I just checked via update.packages() in the R
2.3.0 snapshot I am running -- Version 2.3.0 beta (2006-04-14 r37779) -- and
that doesn't point to the subdir either. 

So that's a bug, but more on the human interaction side between Deepayan,
CRAN and me :)  

Seriously, with the versioned Depends: we can easily produce versions of
packages that depends on the upcoming-but-already-in-Debian releases.  But
someone needs to tell me ....

| > Perhaps email to r-sig-debian?
| 
| Sounds like the proper way to go, so I'm CC-ing.
| 
| I realise that this is a tricky situation: there are multiple copies of
| recommended packages, one set that goes with an R release and another that
| gets updated more or less independently. I'm not sure what the best
| strategy would be from the Debian packaging perspective (perhaps looking
| in both places and choosing the one with higher version number but still
| compatible with the corresponding R version).

I am sure we can work something out.  Generally speaking, I am happy with the
general policy of 'Debian has the most recent R release in unstable, and
hence almost always also in testing' and helping R Core with pre-release in
Debian unstable prior to a new release. The prereleases never make it to
testing -- by ensuring I replace them frequently enough.

This seems to server most of us well.  We can, I think, augment this with
updates of r-recommended in unstable as well.  All we need is proper Depends
a la     Depends: r-base-core (>> 2.2.1)   which would ensure that the
package cannot slip into testing as testing has R 2.2.1 -- whereas unstable
has what I currently call 2.2.1.svn$SVNRELEASE where $SVNRELEASE is the
five-digit number.  

Does this make sense?

Dirk

| 
| Deepayan
| 
| > --
| > Edzer
| >
| > deepayan at cs.wisc.edu wrote:
| >>> Deepayan, after updating to R 2.3.0 (beta), I noticed that levelplot
| >>> now
| >>> seems to draw boxes around the coloured squares. Is this intentional?
| >>> Is
| >>> there
| >>> a way to not draw them? Need I rebuild lattice?
| >>>
| >>
| >> Well, the lattice version should be 0.13-something. Depending on how you
| >> got the R 2.3.0 sources, you may need to run ./tools/rsync-recommended.
| >> Can you check with that? I don't see any problem in my installation.
| >>
| >> Deepayan
| >>
| >>
| >>> Best regards,
| >>> --
| >>> Edzer
| >>>
| >>>  > version
| >>>                _
| >>> platform       i486-pc-linux-gnu
| >>> arch           i486
| >>> os             linux-gnu
| >>> system         i486, linux-gnu
| >>> status         alpha
| >>> major          2
| >>> minor          3.0
| >>> year           2006
| >>> month          04
| >>> day            07
| >>> svn rev        37668
| >>> language       R
| >>> version.string Version 2.3.0 alpha (2006-04-07 r37668)
| >>>  >ip = installed.packages()
| >>>  > ip[row.names(ip) == "lattice",]
| >>>         Package   LibPath                   Version   Priority
| >>> Bundle
| >>> lattice "lattice" "/usr/lib/R/library"      "0.12-11" "recommended" NA
| >>> lattice "lattice" "/usr/lib/R/site-library" "0.12-11" "recommended" NA
| >>>         Contains Depends        Suggests Imports
| >>> lattice NA       "R (>= 2.2.0)" "grid"   "grid, grDevices, graphics,
| >>> stats"
| >>> lattice NA       "R (>= 2.2.0)" "grid"   "grid, grDevices, graphics,
| >>> stats"
| >>>         Built
| >>> lattice "2.2.0"
| >>> lattice "2.2.1"
| >>>  >
| >>>
| >>>
| >>>
| >>
| >>
| >>
| >
| 
| _______________________________________________
| R-SIG-Debian mailing list
| R-SIG-Debian at r-project.org
| https://stat.ethz.ch/mailman/listinfo/r-sig-debian
#
Further to the issue raised by Edzer and Deepayan, I have just uploaded new
and current versions of all the recommended packages that were waiting for R
2.3.0 (i.e. KernSmooth, VR, foreign, lattice, mgcv, nlme, rpart; the boot,
cluster and survival packages were already current via their versions from
the normal CRAN directory src/contrib/).

As these packages have proper Depends on r-base-core (>> 2.2.1), they can now
be used in Debian unstable with the current (and presumably last) snapshot
for R 2.3.0.  This new R release should join them Monday in unstable, and
after the usual 10+ day delay these should all migrate to testing.

Hope this helps,  Dirk