From simons at nospf.cryp.to  Wed Mar  1 10:25:39 2017
From: simons at nospf.cryp.to (Peter Simons)
Date: Wed, 1 Mar 2017 10:25:39 +0100
Subject: [Rd] Test suite failures in R-devel_2017-02-25_r72256
References: <8760jwdlq8.fsf@write-only.cryp.to>
	<22708.16632.500910.453227@stat.math.ethz.ch>
Message-ID: <8760jtjqlo.fsf@write-only.cryp.to>

Hi Martin,

 > Is it necessary to also run the 'make check' part in that restricted
 > environment? Or could that ('checking") not get more priviledges?

in NixOS, there is no way to run any kind of build process in an
environment that has network access. On one hand, that is a security
consideration, but the even more compelling reason for that choice is
that NixOS goes to great lengths to guarantee deterministic builds, and
a build process that connects to servers on the Internet and uses data
they provides is as non-deterministic as it can be, unfortunately.

What we can do for the 3.4.0 release is to extend our build environment
for R to ensure that all required resources are downloaded and made
available locally before the build starts.

 > Note that you can only run  "make check" if you don't install
 > recommended packages, whereas more thorough testing would
 > include
 >      make check-devel
 > or even
 >      make check-all
 >
 > but these do have quite a bit more requirements including recommended
 > packages being present.

Thank you for pointing that out. We do offer our users the choice of
whether they want the recommended packages included or not (the default
choice being to not include them), so we should in fact parameterize our
build to run the extended test suite if the recommended packages are
built.

Another option would be to always build the recommended packages, but to
not install them if the user doesn't want them included. I'm not sure,
though, whether the R build system supports such a type of build easily?

Best regards,
Peter



[Rd] Test suite failures in R-devel_2017-02-25_r72256
Peter Simons