On 9/27/22 18:42, Blätte, Andreas wrote:
Dear all,

my apologies for a dull question. I think I do understand that unnoticed 
Internet access requires scrutiny and a more explicit approach.

But I am not sure how this would impact on the practice on many Windows 
machines to download static libraries from one of the rwinlib repositories? See 
https://github.com/rwinlib, an approach taken by quite a few packages 
(src/Makevars.win triggers tools/winlibs.R for downloading a static library).

I am asking because a package I maintain (RcppCWB) uses the approach, and  am 
not sure whether and how the discussion has addressed this scenario. It may not 
be covered by Iñakis initial three scenario?

Dear Andreas,

please let me clarify for others that your package only downloads pre-compiled static libraries for R 4.1 and earlier on Windows, what is already now the "old release" and will not be checked against by CRAN once R 4.3 is released. For R 4.2 ("release") and R-devel, your package includes the source code of the library and links it, which is in compliance with the CRAN policy. So if any new possible restriction in downloading along the lines Inaki raised was set, it probably won't affect you.

Downloading pre-compiled static libraries is only possible as very last resort and only with agreement of the CRAN team - see the CRAN policy for details (https://cran.r-project.org/web/packages/policies.html, look for "external"). In other words, unless those special conditions are met, it is already banned now.

More explanation for why it is a bad thing can be found in https://cran.r-project.org/bin/windows/base/howto-R-4.2.html:

"For transparency, source packages should contain source (not executable code). Using pre-compiled libraries may lead to that after few years the information on how they were built gets lost or significantly outdated and no longer working. Using older binary code may provide insufficient performance (newer compilers tend to optimize better). Also, the CRAN (and Bioconductor) repositories are used as a unique test suite not only for R itself but also the toolchain, and by re-using pre-compiled libraries, some parts will not be tested. Compiler bugs are found and when fixed, the code needs to be re-compiled. Finally, object files (and hence static libraries, particularly when using C++) on Windows tend to become incompatible when even the same toolchain is upgraded. Going from MSVCRT to UCRT is an extreme case when all such code becomes incompatible, and adding support to 64-bit ARM would be another extreme case, but smaller updates of different parts of the toolchain or even some libraries in it lead to incompatibilities. The issues mentioned here are based on experience with the transition to UCRT and Rtools42; all of these things have happened and dealing with the downloads and re-use of static libraries was one of the biggest challenges."

With respect to any possible restriction on downloading in principle, this is no different from downloading external source code (both is needed when the native code of packages is being built, so during "R CMD INSTALL"), and that has already been mentioned in this thread. So it doesn't have to be discussed specially I think.

Best
Tomas


Kind regards, Andreas





Am 27.09.22, 10:15 schrieb "R-devel im Auftrag von Iñaki Ucar" 
<r-devel-boun...@r-project.org im Auftrag von iu...@fedoraproject.org>:

     El mar., 27 sept. 2022 4:22, Dirk Eddelbuettel <e...@debian.org> escribió:

     >
     > Regarding 'system' libraries: Packages like stringi and nloptr download 
the
     > source of, respectively, libicu or libnlopt and build a library _if_ the
     > library is not found locally.  If we outlaw this, more users may hit a
     > brick
     > wall because they cannot install system libraries (for lack of
     > permissions),
     > or don't know how to, or ...  These facilities were not added to run 
afoul
     > of
     > best practices -- they were added to help actual users. Something to keep
     > in
     > mind.


     Yes, but then IMO Internet access should be explicitly enabled by the user
     with a flag. By default, it should be disabled and packages on CRAN should
     install as is.

     Iñaki

        [[alternative HTML version deleted]]

     ______________________________________________
     R-devel@r-project.org mailing list
     https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel

Reply via email to