Thanks Simon. As far as I can tell, I did not receive any reply to that email; would you mind re-sending it?
Nic On Mon, 29 Jan 2024, 19:31 Simon Urbanek, <simon.urba...@r-project.org> wrote: > Nic, > > as far as I can see that thread was clearly concluded that it is not a > special case that would require external binary downloads. > > Cheers, > Simon > > > > On Jan 30, 2024, at 11:11 AM, Nic Crane <thisis...@gmail.com> wrote: > > > > Hi Simon, > > > > The email that Neal is referring to was sent by me (this email > > address) to c...@r-project.org on Mon, 23 Oct 2023. > > > > Thanks, > > > > Nic > > > > > > On Mon, 29 Jan 2024 at 18:51, Simon Urbanek <simon.urba...@r-project.org> > wrote: > >> > >> Neal, > >> > >> generally, binaries are not allowed since CRAN cannot check the > provenance so it's not worth the risk, and it's close to impossible to > maintain them over time across different systems, toolchains and > architectures as they evolve. Historically, some packages allowed to > provide binaries (e.g., back when the Windows toolchain was not as complete > and there was only Win32 target it was more common to supply a Windows > binary) and CRAN was more lenient, but it should be avoided nowadays as it > was simply too fragile. > >> > >> As Andrew pointed out in special circumstances you can use external > hash-checked *source* tar balls, but generally you should provide sources > in the package. > >> > >> I do not see any e-mail from you to c...@r-project.org about this, so > please make sure you are using the correct e-mail if you intend to plead > your case. > >> > >> Cheers, > >> Simon > >> > >> > >> > >>> On Jan 30, 2024, at 3:11 AM, Neal Richardson < > neal.p.richard...@gmail.com> wrote: > >>> > >>> Hi, > >>> CRAN's policy on using external C/C++/Fortran/other libraries says: > >>> > >>> "Where a package wishes to make use of a library not written solely > for the > >>> package, the package installation should first look to see if it is > already > >>> installed and if so is of a suitable version. In case not, it is > desirable > >>> to include the library sources in the package and compile them as part > of > >>> package installation. If the sources are too large, it is acceptable to > >>> download them as part of installation, but do ensure that the download > is > >>> of a fixed version rather than the latest. Only as a last resort and > with > >>> the agreement of the CRAN team should a package download pre-compiled > >>> software." > >>> > >>> Apologies if this is documented somewhere I've missed, but how does > one get > >>> CRAN's agreement to download pre-compiled software? A project I work > with > >>> has been seeking permission since October, but emails to both > >>> c...@r-project.org and cran-submissi...@r-project.org about this have > not > >>> been acknowledged. > >>> > >>> I recognize that this mailing list is not CRAN, but I was hoping > someone > >>> here might know the right way to reach the CRAN team to provide a > judgment > >>> on such a request. > >>> > >>> Thank you, > >>> Neal > >>> > >>> [[alternative HTML version deleted]] > >>> > >>> ______________________________________________ > >>> R-package-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/r-package-devel > >>> > >> > >> ______________________________________________ > >> R-package-devel@r-project.org mailing list > >> https://stat.ethz.ch/mailman/listinfo/r-package-devel > > > > [[alternative HTML version deleted]] ______________________________________________ R-package-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel
