[Rd] Proposal to limit Internet access during package load

Blätte, Andreas @ndre@@@b|@ette @end|ng |rom un|-due@de
Wed Sep 28 10:09:26 CEST 2022


Dear Tomas, thank you so much for the explanation. Very helpful for myself, and relevant for the wider context of packages using rwinlib!  Andreas

Am 27.09.22, 20:18 schrieb "Tomas Kalibera" <tomas.kalibera using gmail.com>:

    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-bounces using r-project.org im Auftrag von iucar using fedoraproject.org>:
    >
    >      El mar., 27 sept. 2022 4:22, Dirk Eddelbuettel <edd using 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 using r-project.org mailing list
    >      https://stat.ethz.ch/mailman/listinfo/r-devel
    >
    > ______________________________________________
    > R-devel using r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel



More information about the R-devel mailing list