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:
tsflags=nodocs
R.css
--setopt=tsflags=
tsflags
--no-docs
--no-html
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:
include
/usr/include/R
doc
/usr/share/doc/R
# 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.
/usr/share/doc/*
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.
--(no-)html
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)