Skip to content

[R-pkg-devel] Testing package on R-devel in a docker container

3 messages · Ott Toomet, Greg Hunt, Dirk Eddelbuettel

#
Thanks.

I thought this was the issue, and even manually deleted /usr/bin/R and
/usr/bin/Rscript, but the problem persisted.  But now I am thinking that
/usr/bin/R may not be the relevant executables, the development version may
pull up something directly from /usr/lib/R/bin instead (the devel is
installed in /usr/local/lib/R ).

Will try!

Ott

On Sun, Aug 10, 2025 at 9:57?PM Tim Taylor <tim.taylor at hiddenelephants.co.uk>
wrote:

  
  
#
Out of curiosity, why do they install two instances of R in a Docker
container?  On a traditional physical tin server, sure, you can't avoid
that sort of thing, but why in Docker?  I didn't see a rationale for it on
the Rocker wiki or website.

Greg
On Mon, 11 Aug 2025 at 16:05, Ott Toomet <otoomet at gmail.com> wrote:

            

  
  
#
On 11 August 2025 at 18:03, Greg Hunt wrote:
| Out of curiosity, why do they install two instances of R in a Docker
| container?  On a traditional physical tin server, sure, you can't avoid
| that sort of thing, but why in Docker?  I didn't see a rationale for it on
| the Rocker wiki or website.

"They" here. It makes sense to have the underlying base be the r-base
container, and it has R. And because it gets R as a package this is harder to
disentangle afterwards.  Also, my live system also has R and RD so I was used
to _explicitly_ opt into r-devel ...  

Also note that given how R works an honours its installation path, the
following simple 'ln -s RD R' is all you need to have 'RD' be 'R' on that
container too:

  $ docker run --rm -ti rocker/r-devel \
       bash -c 'cd /usr/local/bin && ln -s RD R && R --version'

  (Line break just for exposition here)

but we don't do that by default because having R as well can be useful.

Dirk