`pak::pkg_install()` does not download manylinux binaries from P3M

[AdaemmerP]

Description

In our multi-stage Docker builds, we require a binary-only installation where packages are exclusively pulled from a manylinux URL.

Standard install.packages() works perfectly and downloads the pre-compiled binaries. However, pak::pkg_install() treats the repository strictly as a source repository, forcing full local compilations.

pak::meta_list()[["sources"]] reveals that pak appends /src/contrib/ to the manylinux path instead of parsing it as a binary layout:

[[1]]
[1] "https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/2026-06-01/src/contrib/data.table_1.15.4.tar.gz"

This classification failure could be a regression/side effect of the broader regular expression changes introduced in v0.9.5 (#863). The internal URL classification patterns (such as pkgcache:::is_ppm_linux_repo_url()) do not recognize the manylinux_2_28 distribution string as a valid PPM binary architecture tag, causing pak to fall back to a source mapping strategy.

---

Steps to Reproduce

options(
  repos = c(
    P3M_MANYLINUX = "https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/2026-06-01"
  )
)

# Under the hood, this resolves to /src/contrib/ and triggers a source build:
pak::meta_list("data.table")[["sources"]]

# Fails to pull pre-compiled binary:
pak::pkg_install("data.table")

[gaborcsardi]

pak::meta_list()[["sources"]] reveals that pak appends /src/contrib/ to the manylinux path instead of parsing it as a binary layout:

What is the correct URL then? AFAICT install.packages() downloads the same URL:

> options(
  repos = c(
    P3M_MANYLINUX = "https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/2026-06-01"
  )
)
> install.packages("data.table")
Installing package into ‘/root/R/x86_64-pc-linux-gnu-library/4.6’
(as ‘lib’ is unspecified)
trying URL 'https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/2026-06-01/src/contrib/data.table_1.18.4.tar.gz’
...

[AdaemmerP]

Mmm... That is true. However, it seems install.packages() downloads the file:

> install.packages("data.table")
trying URL 'https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/2026-06-01/src/contrib/data.table_1.18.4.tar.gz'
Content type 'binary/octet-stream' length 3207083 bytes (3.1 MB)
==================================================
downloaded 3.1 MB

* installing *binary* package ‘data.table’ ...
* package ‘data.table’ successfully unpacked and SHA256 sums checked
* DONE (data.table)

... whereas pak (says it) is building it ([bld][cmp]). This is also happening in our Docker image:

pak::pkg_install("data.table")
                                                                          
→ Will install 1 package.
→ Will download 1 package with unknown size.
+ data.table   1.18.4 [bld][cmp][dl]
  
ℹ Getting 1 pkg with unknown size
✔ Got data.table 1.18.4 (source) (3.21 MB)                                
✔ Downloaded 1 package (3.21 MB) in 655ms                                 
ℹ Building data.table 1.18.4
✔ Built data.table 1.18.4 (642ms)                                
✔ Installed data.table 1.18.4  (37ms)                              
✔ 1 pkg: added 1, dld 1 (3.21 MB) [1.7s]    

[AdaemmerP]

... Another example for sf. pak builds it from source and needs almost 7 minutes:

> pak::pkg_install("sf")
✔ Loading metadata database ... done
                                                                          
→ Will install 7 packages.
→ Will download 1 CRAN package (2.97 MB), cached: 6 (0 B).
+ classInt   0.4-11 [bld][cmp]
+ e1071      1.7-17 [bld][cmp]
+ proxy      0.4-29 [bld][cmp]
+ s2         1.1.11 [bld][cmp][dl] (2.97 MB) + ✖ libabsl-dev, ✔ cmake, ✔ libssl-dev
+ sf         1.1-1  [bld][cmp] + ✖ libgdal-dev, ✖ gdal-bin, ✖ libgeos-dev, ✖ libproj-dev, ✖ libsqlite3-dev
+ units      1.0-1  [bld][cmp] + ✖ libudunits2-dev
+ wk         0.9.5  [bld][cmp]
✖ Missing 7 system packages. You'll probably need to install them manually:
+ gdal-bin         - sf   
+ libabsl-dev      - s2   
+ libgdal-dev      - sf   
+ libgeos-dev      - sf   
+ libproj-dev      - sf   
+ libsqlite3-dev   - sf   
+ libudunits2-dev  - units
ℹ Getting 1 pkg (2.97 MB), 6 cached
✔ Got proxy 0.4-29 (source) (178.55 kB)                                                        
✔ Got units 1.0-1 (source) (555.21 kB)                                                         
✔ Got e1071 1.7-17 (source) (622.88 kB)                                                        
✔ Got s2 1.1.11 (source) (2.97 MB)                                                            
✔ Got wk 0.9.5 (source) (1.76 MB)                                                             
✔ Got classInt 0.4-11 (source) (1.52 MB)                                           
✔ Got sf 1.1-1 (source) (72.78 MB)                                             
✔ Downloaded 7 packages (80.39 MB) in 23.5s                       
ℹ Building proxy 0.4-29
ℹ Building units 1.0-1
ℹ Building wk 0.9.5
✔ Built proxy 0.4-29 (380ms)                                             
✔ Installed proxy 0.4-29  (74ms)                                                    
ℹ Building e1071 1.7-17                                                             
✔ Built units 1.0-1 (516ms)                                                        
✔ Installed units 1.0-1  (1s)                                                       
✔ Built wk 0.9.5 (1.5s)                                                            
✔ Built e1071 1.7-17 (1.1s)                                       
✔ Installed e1071 1.7-17  (20ms)                                 
ℹ Building classInt 0.4-11                                      
✔ Installed wk 0.9.5  (32ms)                                                    
ℹ Building s2 1.1.11                                                            
✔ Built classInt 0.4-11 (770ms)                                                
✔ Installed classInt 0.4-11  (48ms)                                              
✔ Built s2 1.1.11 (5m 54.3s)                                                    
✔ Installed s2 1.1.11  (419ms)                                 
ℹ Building sf 1.1-1                                            
✔ Built sf 1.1-1 (31.6s)                                      
✔ Installed sf 1.1-1  (1.1s)                                   
✔ 1 pkg + 11 deps: kept 4, added 7, dld 7 (80.39 MB) [6m 56.8s]

... install.packages() simply downloads the binary in some seconds:

install.packages("sf")
Installing package into ‘/home/xyz/R/x86_64-pc-linux-gnu-library/4.6’
(as ‘lib’ is unspecified)
trying URL 'https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/2026-06-01/src/contrib/sf_1.1-1.tar.gz'
Content type 'binary/octet-stream' length 72782721 bytes (69.4 MB)
==================================================
downloaded 69.4 MB

* installing *binary* package ‘sf’ ...
* package ‘sf’ successfully unpacked and SHA256 sums checked
* DONE (sf)

The downloaded source packages are in
	‘/tmp/Rtmp3YPnGH/downloaded_packages’

[AdaemmerP]

I did some further digging and found that pkgcache:::is_ppm_linux_repo_url() does not recognize manylinux_2_28 as a valid distro token on my machine (I have Ubuntu 26.04. resolute):

pkgcache:::is_ppm_linux_repo_url(
  "https://packagemanager.posit.co/cran/__linux__/resolute/latest"
)
#> [1] TRUE
 
pkgcache:::is_ppm_linux_repo_url(
  "https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/latest"
)
#> [1] FALSE

Would changing [a-zA-Z0-9]+ to [a-zA-Z0-9_]+ in re_ppm_linux() fix this? At least on my end this seems to work:

grepl(
  "^(?<base>.*/)(?<repo>[^/]+)/__linux__/(?<distro>[a-zA-Z0-9_]+)/(?<version>latest|[-0-9]+)$",
  "https://packagemanager.posit.co/cran/__linux__/manylinux_2_28/latest",
  perl = TRUE
)
#> [1] TRUE

[gaborcsardi]

Should be fixed in dev pak, if you install from source, or wait for tomorrow's nightly builds [1].

[1] https://pak.r-lib.org/reference/install.html#nightly-builds

[AdaemmerP]

Great, thanks!

[AdaemmerP]

While testing the manylinux_2_28 regex fix, I found that after upgrading pak I still got platform = "source" for packages from a __linux__/manylinux_2_28/... repo.

pkgcache's metadata cache (~/.cache/R/pkgcache/_metadata) was written before the regex fix, when bin_url was NA for this repo. That gets reused, so PACKAGES2.gz (the binary listing) never gets fetched and the package stays flagged as "source".

I tried pkgcache::meta_cache_cleanup(force = TRUE) to force a refresh, but it throws a warning ("expanded path length ... would be too long") and doesn't actually clean the replica cache. The bug is in cmc_cleanup():

local_cache_dir <- private$get_cache_files("replica")
unlink(local_cache_dir, recursive = TRUE, force = TRUE)

get_cache_files("replica") returns a list (root, meta, lock, rds, pkgs data frame, ...), not a path — so unlink() gets handed the whole structure coerced into one giant string.

Fix: add $meta:

local_cache_dir <- private$get_cache_files("replica")$meta
unlink(local_cache_dir, recursive = TRUE, force = TRUE)

Now, data.table from a manylinux_2_28 PPM repo correctly resolves to platform = x86_64-pc-linux-gnu-ubuntu-26.04 (binary) instead of "source".

Do you agree with the problem and fix? Shall I open a PR for the meta_cache_cleanup() ?

[gaborcsardi]

Sorry for the wait, I think the cache deletion issue is fixed in pkgcache and also in pak.