Are you sure the issue that CRAN has is the library sizes, and not the issues flagged by the "LTO" platform <> ?

I would check with CRAN for clarification before you spend a lot of time trying to reduce package sizes. As you point out, lots of packages on CRAN have package sizes large enough to trigger this note -- it is my impression that CRAN only object if the large package size is considered unnecessary; some of the *inappropriate* reasons for large package size are listed in the repository policy <>

Packages should be of the minimum necessary size. Reasonable compression should be used for data (not just .rda files) and PDF documentation: CRAN will if necessary pass the latter through qpdf.

As a general rule, neither data nor documentation should exceed 5MB (which covers several books). A CRAN package is not an appropriate way to distribute course notes, and authors will be asked to trim their documentation to a maximum of 5MB.

Where a large amount of data is required (even after compression), consideration should be given to a separate data-only package which can be updated only rarely (since older versions of packages are archived in perpetuity).

Similar considerations apply to other forms of “data”, e.g., .jar files.

Source package tarballs should if possible not exceed 10MB. It is much preferred that third-party source software should be included within the package (as e.g. a vendor.tar.xz file) than be downloaded at installation: if this requires a larger tarball a modestly increased limit can be requested at submission.

On 2024-01-20 2:38 p.m., Johann Gaebler wrote:
Hi everyone,

I received the following message regarding  `rar` 
<>, a package that I put up on CRAN two 
days ago:

Dear maintainer,

Please see the problems shown on

Please correct before 2024-02-02 to safely retain your package on CRAN.

The issue is that the compiled libraries are too large. The Mac CRAN checks 
turned up the following note:

installed size is  8.9Mb
sub-directories of 1Mb or more:
  libs   8.7Mb

I have not been able to reproduce the issue either locally or on any machine I 
have ready access to. I have built it on some of the Rhub and R-Project build 
systems, and the same issue (with very different `libs` sizes) came up on some 
of them:

• (RHub) Ubuntu Linux 20.04.1 LTS, R-release, GCC: 18.2Mb,
• (RHub) Fedora Linux, R-devel, clang, gfortran: 6.8Mb,
• (R-Project) r-release-macosx-arm64: 8.5Mb.

Based on trying to read up about this, it seems that this is a pretty common problem 
for compiled packages because of debugging symbols getting inserted into the shared 
library file. Using the fix from that blog post where you modify the Makevars to 
strip debugging symbols from the shared library seems to solve the issue on those 
build systems, so I feel reasonably confident that this is what’s going on.

Apparently many, many existing packages on CRAN have the same issue. However, 
I’m very new to R package development, so I’m not exactly sure what to do. I 
have two questions:

1. Is there anything I need to “fix” here, or should I just make contact with 
the CRAN folks and bring the fact that this is being caused by debugging 
symbols to their attention?
2. Regardless of whether or not I have to fix this issue for CRAN, is there a 
way to strip out the debugging symbols that comports with CRAN policies? The 
method suggested in the blog post above (adding a phony target in `Makevars` 
that strips the shared library) seems not to be CRAN-compliant, but I could be 
mistaken about that. (In particular, I had to modify it locally to get it to 
run, so I’m not sure what the platform-independent version of it looks like.)

Thanks in advance for the help!

Johann D. Gaebler
        [[alternative HTML version deleted]]

______________________________________________ mailing list

Dr. Benjamin Bolker
Professor, Mathematics & Statistics and Biology, McMaster University
Director, School of Computational Science and Engineering
(Acting) Graduate chair, Mathematics & Statistics
> E-mail is sent at my convenience; I don't expect replies outside of working hours.

______________________________________________ mailing list

Reply via email to