[R-pkg-devel] About the CRAN policy on downloading pre-compiled binary

Tomas Kalibera tom@@@k@||ber@ @end|ng |rom gm@||@com
Wed Jul 27 10:12:31 CEST 2022


On 7/27/22 08:08, Tomas Kalibera wrote:
>
> On 7/27/22 00:30, Hiroaki Yutani wrote:
>> Hi,
>>
>> Recently I got the following email from the CRAN maintainer about my
>> package, string2path[1].
>>
>> However, I do ensure the binary is the pinned version and verify if the
>> hash matches with the embedded one in the DESCRIPTION [2][3]. In case 
>> of a
>> mismatch, the build fails. So, this mechanism should ensure that I (or
>> anyone) cannot change the version of the binary without actually
>> resubmitting to CRAN.
>
> Please see the policy cited. Ensuring that the download is of a fixed 
> version refers to the sources (which can be downloaded under the 
> conditions mentioned).
>
> Downloading binaries are only a last resort option and requires the 
> agreement of the CRAN team in the first place.
>
>> I believe this complies with the CRAN policy (except for not clearing 
>> the
>> authorship and copyright). Is there anything I have to address to 
>> prove I
>> do "ensure that the download is of a fixed version"? Any suggestions are
>> welcome.
>
> My understanding from your email is you are ensuring a fixed version 
> download, and with most projects you could probably do even less 
> (simply hardcode a URL which includes a specific version of the 
> sources if that is stable for the project), but you are not 
> downloading sources.

I take back the comment about doing less to ensure a fixed version - it 
is good to use a hash always when having to download sources, as 
software distributions do (of course including MXE and Msys2, so Rtools 
on Windows, etc). It is better as a guard against that the content is in 
fact not stable for the project (I've been told it sometimes happens and 
may be surprising to package authors), but of course also for security 
reasons.

Tomas
>
> In either case, of course if there is anything unclear in an email 
> from CRAN, you can simply respond to that and ask.
>
> Best
> Tomas
>
>>
>> The CRAN policy stipulates
>>> "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."
>>>
>>> and we have recently seen an instance of a rust-using package whose
>>> check output changed because what it downloaded had changed. CRAN
>>> checking is not set up for that (for example, macOS checks are done 
>>> once
>>> only for each version).
>>>
>>> Whilst investigating, the Windows' maintainers found that binary libs
>>> were being downloaded.  And subsequently I found that salso, 
>>> string2path
>>> and ymd are downloading compiled code on Intel macOS.
>>>
>>> Also. make sure that the authorship and copyright of code you download
>>> (and hence include in the package) is clear from the DESCRIPTION file.
>>> as required by the CRAN policy.
>>>
>> Best,
>> Hiroaki Yutani
>>
>> [1]: https://cran.r-project.org/package=string2path
>> [2]:
>> https://github.com/cran/string2path/blob/46020296410cd78e2021bff86cb6f17c681d13a6/DESCRIPTION#L29-L40 
>>
>> [3]:
>> https://github.com/cran/string2path/blob/46020296410cd78e2021bff86cb6f17c681d13a6/tools/configure.R#L177-L295 
>>
>>
>>     [[alternative HTML version deleted]]
>>
>> ______________________________________________
>> R-package-devel using r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-package-devel



More information about the R-package-devel mailing list