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,
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
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 wrote:
>
> Neal,
>
> generally, binaries are not allowed since CRAN cannot check the provenance so
> it's not w
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 wrote:
>
> Hi Simon,
>
> The email that Neal is referring to was sent by me (this email
> address) t
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.
Personally haven't had anyone raise an issue with mine downloading
hash-verified git-tagged tarballs, but I don't know if that's because my
package is having other issues or if that's because its generally
acceptable.
-Andrew
On 1/29/2024 9:11 AM, Neal Richardson wrote:
Hi,
CRAN's policy on
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
