#2 Add info about docker usage
Closed by iucar. Opened by iucar.

See this thread. Our docker images have tsflags=nodocs set. This causes a warning when installing new packages from source, because R.css is not present. We should document this and describe alternatives:

  • Installing R-core with --setopt=tsflags= will reset tsflags and thus will install R's docs.
  • Installing packages with --no-docs (--no-html?) does not issue a warning.

Additionally, is there anything we can do (from the R packaging perspective) to force --no-docs (--no-html?) in containers? (While adhering to the packaging guidelines).


Other factor: I believe /usr/share/doc is the path that R upstream puts R.css into and that dir is a docdir by default.

We have:

$ tree  -L 1 /usr/share/R
/usr/share/R
├── dictionaries
├── encodings
├── java
├── library
├── licenses
├── make
├── R
├── Rd
├── sh
└── texmf

and include in /usr/include/R and doc in /usr/share/doc/R. For me, this makes more sense than this:

# tree -L 2 /usr/share/R 
/usr/share/R
|-- doc
|   |-- ...
|   |-- html
|   `-- manual
|-- include
|   |-- R_ext
|   |-- ...
`-- share
    |-- R
    |-- Rd
    |-- dictionaries
    |-- encodings
    |-- java
    |-- licenses
    |-- make
    |-- sh
    `-- texmf

That's Ubuntu 20.04. So in their containers they also exclude /usr/share/doc/* to minimize image sizes, but their R packaging escapes this minimization rule because doc is in another path.

It would be great if --(no-)html, which is set at compile time, could also be controlled via an environment variable, but it doesn't seem to be the case.

We could redefine rdocdir like Ubuntu does. While I agree that /usr/share/doc/ is the most correct place, I don't think there is an easy way to always install R.css in rdocdir in a --no-docs scenario.

I mean, I'm happy with current packaging, I don't think we should modify how R.css is installed. Given that we cannot force --no-html in source installations when R-core is installed without docs (which would be the proper way to go), warnings are fine: as demonstrated in numerous threads where people complain about devtools/remotes converting warnings into errors, people tend to just go on with warnings. But it's fair to document them, so I'll reflect that in our page on CRAN.

Metadata Update from @iucar:
- Issue status updated to: Closed (was: Open)

Metadata