pkgcache internals

Gábor Csárdi

2026-07-30

Platforms

• get_cran_extension()
• get_all_package_dirs()
• async_repo_status()
• packages_make_target()
• packages_make_sources()
• cmc__get_cache_files()
• current_r_platform()
• default_platforms()

Windows

Windows is special, because the same repository is used for multiple architectures. Probably most people use 64 bit R on Windows, because that’s what RStudio starts by default. But we also need to make sure that people who need 32 bit R will have a way to install packages, without ruining the 64 bit installation.

Luckily, there are no packages on CRAN or Bioconductor currently that are 32 bit only. (There are a few that are 64 bit only.) In addition, 32 bit R currently installs the package for both architectures, when installing from source. (64 bit R-devel does the same currently, but this might change.)

In light of these, this is what we do:

• The default platform is x86_64-w64-mingw32 on 64 bit R from R 4.2. It is i386+x86_64-mingw32 on 64 bit R before R 4.2.
• The default platform is i386+x86_64-w64-mingw32 on 32 bit R.
• The windows platform name is an alias to i386+x86_64-w64-mingw32.
• When compiling a package from source, we’ll observe the requested platform name:
  • For x86_64-w64-mingw32 on 64 bit R, we compile 64 bit only.
  • For i386-w64-mingw32 on 64 bit R, we compile for both 32 bit and 64 bit. (There is probably no way to avoid using the current arch.)
  • For i386+x86_64-w64-mingw32 on 64 bit R, we compile for both 32 bit and 64.
  • For i386-w64-mingw32 on 32 bit R, we compile for both 32 bit and 64 bit. This is to avoid mistakenly messing up a 64 bit library.
  • For x86_64-w64-mingw32 on 32 bit R, we compile for both 32 bit and 64 bit. (There is probably no way to avoid using the current arch.)
  • For i386+x86_64-w64-mingw32 on 32 bit R, we compile for both 32 bit and 64 bit.

In summary, when compiling packages, we compile for both archs, except if we are in a 64 bit R session and the platform is x86_64-w64-mingw32.

Custom binary package types

From R 4.6.0 .Platform$pkgType may be a custom binary package type of the form <system>.binary.<build>, where <system> is the lower case name of the system and <build> is the name of the build. The author of a binary R distribution sets this with the R_PLATFORM_PKGTYPE environment variable. The matching repository layout, from utils::contrib.url(), is bin/<system>/<build>/contrib/<x.y>, with mac mapped to macosx and win mapped to windows. This is a generalization of the mac.binary.<subdir> types that macOS has been using for a long time.

In light of this, this is what we do:

• The platform name is the usual cpu-vendor-os platform string, with the package type appended, e.g. aarch64-w64-mingw32-windows.binary.clang-aarch64 for Windows on arm64. Two different builds of R for the same platform triple must remain distinguishable, and the platform triple on its own cannot do that.
• We keep the literal .binary in the platform name. It makes it clear that the suffix is a .Platform$pkgType, and it is a reliable anchor when parsing a platform name, because no other part of a platform name may contain it. This is what makes a package type work together with the Linux distribution and release parts of a platform name.
• We only append the package type if it is a custom one, i.e. not win.binary and not mac.binary[.<subdir>]. pkgcache has always had platform names for those, so the platform names on Windows and macOS do not change.
• The file extension follows <system>: .zip for windows and .tgz for macosx, the same as R CMD INSTALL --build produces, no matter whether the package type is a custom one.
• A platform name without a package type is unchanged. In particular a plain aarch64-w64-mingw32 must not be served the x86_64 binaries from bin/windows/contrib.
• A package type on its own is not a valid platform name, it needs the platform triple as well.