[R-SIG-Mac] CRAN metadata inconsistencies for macOS binaries

[Simon Urbanek]

Gábor,

it is not a mirror, just the main source of Mac binaries, so what I was saying is that if you have a temporary problem with your regular mirror, then you can use it to circumvent that problem. It is ideally located for US users (it is in a Dallas data center), but clearly will be slower from other places - but it is certainly not intended as a CDN.

Anything beyond that source is not under my control, I don't actually know how the mirrors get populated, so that would be probably a discussion at CRAN level. I know that sources are handled by temporary symlinks to the archive for a short time so old versions work temporarily, but since binaries don't have an archive we don't have a provision for that. I guess it would be possible to not delete the old packages during the PACKAGES sync but keep them around longer if some additional sweep or delay was implemented.

Historically, Mac binaries have been built incrementally, so each sync is typically small so it is very unlikely for the problem to occur. My only guess is that with the R-devel re-builds they got larger than usual which may have possibly led to issue. The other possibility could be that some network issues could abort a sync which then only gets retried later and the repository is inconsistent in the meantime - but hat's beyond my control. All syncs are anonymous pulls so I don't have the logs so can't really tell.

Cheers,
Simon


> On 12/12/2025, at 8:50 PM, Gábor Csárdi <csardi.gabor using gmail.com> wrote:
> 
> Are you fine with using the mac.r-project.org server as a default mirror on macOS? E.g. in RStudio, on GitHub Actions, etc? That's a lot of traffic.
> 
> mac.r-project.org is also not ideally located (i.e. much slower) for most users, especially compared to the CDN at cloud.r-project.org.
> 
> Do you think it would be possible to keep the old binary packages around for a day or so? That would not only help with the sync issue, but also with potentially outdated metadata. AFAIR this is what Debian/Ubuntu repositories do.
> 
> Thanks,
> Gabor
> 
> On Fri, Dec 12, 2025 at 3:16 AM Simon Urbanek
> <simon.urbanek using r-project.org> wrote:
>> 
>> Gábor,
>> 
>> if the update is big enough then it is possible that the packages are synced before the index due to the time it takes to transfer all the content. If you have issues, please use the master server, i.e.,
>> 
>> install.packages("proxy", repos="https://mac.r-project.org")
>> 
>> since that one is guaranteed to be consistent: it is populated by first copying all new packages from the build machines and only then the index is updated and only after that the old versions are deleted. You can check if a mirror may be inconsistent by checking for the existence of the "00_COPYING…" file in the repository - that one is copied before the first package and is removed when the index is synced.
>> 
>> Cheers,
>> Simon
>> 
>> 
>>> On 12 Dec 2025, at 10:15, Gábor Csárdi <csardi.gabor using gmail.com> wrote:
>>> 
>>> This has been happening recently for newly published packages. The new
>>> binary is built, the old one is removed, but the metadata is not
>>> updated yet, at least not on the main CRAN server.
>>> 
>>> ❯ install.packages("proxy", repos = "https://cran.r-project.org")
>>> Installing package into ‘/Users/gaborcsardi/Library/R/arm64/4.5/library’
>>> (as ‘lib’ is unspecified)
>>> trying URL 'https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.5/proxy_0.4-27.tgz'
>>> Error in download.file(urls, destfiles, "libcurl", mode = "wb", ...) :
>>> cannot open URL
>>> 'https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.5/proxy_0.4-27.tgz'
>>> In addition: Warning message:
>>> In download.file(urls, destfiles, "libcurl", mode = "wb", ...) :
>>> cannot open URL
>>> 'https://cran.r-project.org/bin/macosx/big-sur-arm64/contrib/4.5/proxy_0.4-27.tgz':
>>> HTTP status was '404 Not Found'
>>> Warning in download.packages(pkgs, destdir = tmpd, available = available,  :
>>> download of package ‘proxy’ failed
>>> 
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac using r-project.org
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>> 
>> 
>