rstudio container get 'testing' is invalid when try apt-get install

[arthurtalkgoal]

I have an strange "testing" value when I try to run apt-get install in my rstudio container

root@af6beae748de:~# apt-get install vum
Reading package lists... Done
E: The value 'testing' is invalid for APT::Default-Release as such a release is not available in the sources

[eddelbuettel]

You need to do 'apt-get update first, then it will work.

[Starfox899]

I can confirm apt-get update is solving this particular problem. It seems the base image is a little outdated.

[eddelbuettel]

The apt archives get updated several times a day whereas out containers may be days or weeks or months old. In short, you always have to run apt-get update.

[kuamit5516]

E: The value '“testing”' is invalid for APT::Default-Release as such a release is not available in the sources

root@kalilinux:/home/user# sudo apt-get install aptitude
Reading package lists... Done
E: The value '“testing”' is invalid for APT::Default-Release as such a release is not available in the sources

[eddelbuettel]

That is temporary because the current container uses unstable by default to get us R 3.5.0 which is not yet in Debian testing or unstable as it requires a full transition, detail about that are here (and as of today this has not started).

We expect to flip back to testing once the archive is back to normal.

You should be able to install packages from unstable as needed -- just do apt-get install mypackage.

[gbisaga]

This is not working for me. I'm using a freshly-installed Debian 9 amd64. I've tried both with and without the "apt-get update" (is this still necessary, 6 months later?) and get two different bad results.

$ uname -a
Linux debian 4.9.0-8-amd64 #1 SMP Debian 4.9.130-2 (2018-10-27) x86_64 GNU/Linux

$ more Dockerfile
FROM r-base:latest
RUN apt-get update
RUN apt-get install -y libcurl4-openssl-dev

$ docker build .
Sending build context to Docker daemon 122.4MB
Step 1/3 : FROM r-base:latest
---> bd9edc1a85ed
Step 2/3 : RUN apt-get update
---> Using cache
---> 73220b297298
Step 3/3 : RUN apt-get install -y libcurl4-openssl-dev
---> Running in d49ebc027df3
Reading package lists...
Building dependency tree...
Reading state information...
Some packages could not be installed. This may mean that you have
requested an impossible situation or if you are using the unstable
distribution that some required packages have not yet been created
or been moved out of Incoming.
The following information may help to resolve the situation:

The following packages have unmet dependencies:
libcurl4-openssl-dev : Depends: libcurl4 (= 7.61.0-1) but 7.62.0-1 is to be installed
E: Unable to correct problems, you have held broken packages.
The command '/bin/sh -c apt-get install -y libcurl4-openssl-dev' returned a non-zero code: 100

If I remove the apt-get update:

$ docker build .
Sending build context to Docker daemon 122.4MB
Step 1/2 : FROM r-base:latest
---> bd9edc1a85ed
Step 2/2 : RUN apt-get install -y libcurl4-openssl-dev
---> Running in 1b3322635554
Reading package lists...
E: The value 'testing' is invalid for APT::Default-Release as such a release is not available in the sources
The command '/bin/sh -c apt-get install -y libcurl4-openssl-dev' returned a non-zero code: 100

Am I doing something wrong? Thanks in advance.

[cboettig]

@gbisaga The r-base container is built on Debian testing with apt-pinning to debian:unstable. As the names imply, these builds change on a rolling basis, so depending on where things are in the release you will always need to switch back and forth between getting things from unstable (using, e.g. apt-get install -t unstable -y libcurl4-openssl-dev etc). If you don't like life on the bleeding edge like this, you can use the rocker/r-ver stack; which builds on stable releases only (debian:stretch at the moment) without any apt pinning. This means the apt-get command will always work the same way, but it also means that you need to install additional R packages from source, since Debian:stretch doesn't ship with the latest version of R. For this reason, we package the r-ver stack with a bunch of prebuilt common R packages (e.g. rocker/tidyverse). Hope this helps and sorry for the confusing.

[gbisaga]

Thanks a lot @cboettig ! I didn't understand that r-base was bleeding edge. (Although, honestly I did wonder about using Debian testing as ITS base.) Thanks for the pointer!

[cboettig]

Yeah, exactly. Trade-offs on both sides. The upside of the apt-pinning testing & unstable means that you can apt-get -y install r-cran-* packages; on the r-ver images you just have to install.packages() and manage system dependencies manually. Figuring out the best way to document these trade-offs..

[eddelbuettel]

testing gets you current compilers and other tools. I want that, and that is how I set it up.

If you want something ancient but stable, just pick it. Plenty of containers for Debian stable or Ubuntu LTS. I sometimes use them too. They all have R as well but generally the one that was current when that release was current. Mixing "brand-new R" with "ancient distros" is possible but much more work for which we do not have the bandwidth.

Lastly, there is a documentation need but in Debian we only have a few hundred r-cran-* whereas CRAN has 13k.