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
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison