Thank you, Ivan, for your really thoughtful feedback! I really appreciate
it!
- I'll see if there are any base R packages that support SHA-2 or SHA-3.
- I'll see if I can get the configure.ac to make the appropriate Rscript
call for configure.win.
- I think the idea of having a single `confgure.ac` file to generate
both configure and configure.win is nice. Guidance with GitHub
actions and
ChatGPT is essentially a must for me since my bash is remedial at best.
Regarding the permanent storage requirement, I find it to be very strange.
I've personally never heard of Zenodo until just now! Does the CRAN team
have recommendations for what is considered "as sufficiently reliable?" I
have repos that have persisted for almost 10 years. I think that is
sufficiently reliable!
The requirement to avoid GitHub feels surprisingly anachronistic given how
central it is to the vast majority of software development. The alternative
I can think of is to create a CDN on cloudflare or something to store the
file independently.
Are there any avenues to have CRAN clarify their positions outside of
one-off processes? It would be quite unfortunate to go through all the work
of creating a way to build, store, and retrieve the dependencies only for
CRAN to decide they don't support it.
On Wed, May 8, 2024 at 3:32 PM Ivan Krylov <ikry...@disroot.org> wrote:
> В Wed, 8 May 2024 14:08:36 -0400
> Josiah Parry <josiah.pa...@gmail.com> пишет:
>
> > With ChatGPT's ability to write autoconf, I *think *I have something
> > that can work.
>
> You don't have to write autoconf if your configure.ac is mostly a plain
> shell script. You can write the configure script itself. Set the PATH
> and then exec "${R_HOME}/bin/Rscript" tools/configure.R (in the
> regular, non-multiarch configure for Unix-like systems) or exec
> "${R_HOME}/bin${R_ARCH_BIN}/Rscript.exe" tools/configure.R (in
> configure.win, which you'll also need). You've already wrote the rest
> of the code in a language you know well: R.
>
> Autoconf would be useful if you had system-specific dependencies with
> the need to perform lots of compile tests. Those would have been a pain
> to set up in R. Here you mostly need sys.which() instead of
> AC_CHECK_PROGS and command -v.
>
> > The configure file runs tools/get-deps.R which will download the
> > dependencies from the repo if available and verify the checksums.
>
> One of the pain points is the need for a strong, cryptographically
> secure hash. MD5 is, unfortunately, no longer such a hash. In a cmake
> build, you would be able to use cmake's built in strong hashes (such as
> SHA-2 or SHA-3). The CRAN policy doesn't explicitly forbid MD5; it only
> requires a "checksum". If you figure out a way to use a strong hash
> from tools/configure.R for the downloaded tarball, please let us know.
>
> > If the checksums don't match, an error is thrown, otherwise it can
> > continue. I believe this meets the requirements of CRAN?
>
> The other important CRAN requirement is to store the vendor tarball
> somewhere as permanent as CRAN itself (see the caveats at the bottom of
> https://cran.r-project.org/web/packages/using_rust.html), that is, not
> GitHub. I think that Zenodo counts as a sufficiently reliable store.
>
> --
> Best regards,
> Ivan
>
[[alternative HTML version deleted]]
______________________________________________
R-package-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-package-devel
