Staging blocks from other packages seems to be incorrect

[eitsupi]

Currently, the staging issue of nanoarrow and adbcdrivermanager show the following:
https://r-multiverse.org/status/staging.html

R-multiverse found issues with package nanoarrow version 0.7.0 remote hash 2cfba631b40886f1418a463f3b7c4552c8ae0dc7 (last published at 2025-10-14 03:16:11.792 UTC).

On CRAN, this package had version 0.7.0-1 during the first day of the most recent R-multiverse dependency freeze. The version on R-multiverse is lower, which causes install.packages() to prefer CRAN. If you have not already done so, please ensure the latest GitHub/GitLab release has a suitably recent version in the DESCRIPTION file.

R-multiverse found issues with package adbcdrivermanager version 0.20.0 remote hash 56a3ba7135c9dd71cf4b71a3c121184561de3a0a (last published at 2025-10-16 02:53:52.631 UTC).

One or more strong R package dependencies have issues: nanoarrow. Dependency nanoarrow is explicitly mentioned in 'Depends:', 'Imports:', or 'LinkingTo:' in the DESCRIPTION file of adbcdrivermanager.

However, this seems quite strange.
adbcdrivermanager actually works with nanoarrow on CRAN (because it requires nanoarrow (>= 0.3.0))¹, so there's no problem if nanoarrow 0.7.0 isn't in the production snapshot.

Conversely, if nanoarrow hadn't been registered on R-multiverse, adbcdrivermanager would have been able to enter the production repository without any problems.
I feel that this means that the more packages registered in R-multiverse, the less user-friendly the production repository becomes.

Some thoughts:

• Is it really desirable to flag an issue because the version number is older than CRAN's?
• Is it possible to remove a failed package from the staging universe for a period of time, so that packages that depend on it can install their dependencies from CRAN and check whether they pass the tests?
  In this case, nanoarrow should be removed from the staging universe for a certain period of time, and if adbcdrivermanager passes testing during that time, it should be added to the production repository.

Footnotes

1. https://github.com/apache/arrow-adbc/blob/56a3ba7135c9dd71cf4b71a3c121184561de3a0a/r/adbcdrivermanager/DESCRIPTION#L26-L27 ↩

[wlandau]

That's a good point to bring up.

Is it really desirable to flag an issue because the version number is older than CRAN's?

In the general case, yes. The issue is that install.packages() chooses the highest versions of whatever packages it downloads, regardless of the order of the URLs in the repos argument. Without the version check in Staging, nanoarrow 0.7.0 would be distributed in Production even though abcdrivermanager was actually tested against nanoarrow 0.7.0-1 (CRAN). That's confusing for users and subtlety problematic for companies that may ingest entire R-multiverse snapshots wholesale.

Is it possible to remove a failed package from the staging universe for a period of time, so that packages that depend on it can install their dependencies from CRAN and check whether they pass the tests?

Whether the removal is permanent or temporary, it feels like an edge case that novice or intermediate contributors may have trouble understanding, and the implications for the snapshot model are complicated. I think the easiest solution is just for the maintainer of abcdrivermanager to ask the maintainer of nanoarrow to create a new release on GitHub. As R-multiverse scales, both checks in Staging and new package registrations will rely on this kind of open cross talk throughout the community.

[eitsupi]

In that case, a package that is excluded because it is obviously older than the CRAN version should not exclude downstream packages.

Why should abcdrivermanager be excluded from the production repository when nanoarrow does not exist in the production repository and abcdrivermanager is guaranteed to install with nanoarrow from CRAN and passes testing?

I think the easiest solution is just for the maintainer of abcdrivermanager to ask the maintainer of nanoarrow to create a new release on GitHub.

If it were possible to create a release on GitHub, the maintainer would probably already be doing so.
The problem with monorepos is that they likely can't create a GitHub release just for the R package.

This is especially true for the arrow packages, who can only create a release once every two months, and often find an issue with the R package and create a patch for CRAN right after creating a release.

[wlandau]

Are monorepos all that common?

[eitsupi]

Are monorepos all that common?

At least all packages under the ASF umbrella are monorepos, and duckdb was once a monorepo as well.

Also, because the parties that decide when to release a CRAN release and a GitHub release are different, I think this problem could occur even outside of monorepos.
In other words, the final decision on a CRAN release is made by CRAN, but the final decision on a GitHub release is made by the developer.
In this case, it seems contradictory for R-multiverse not to respect the developer's wishes.

[eitsupi]

On second thought, I think we should stick with our current setup.
This is because packages on R-multiverse may be updated after the CRAN mirror date is pinned, and once a package on R-multiverse passes, its version is pinned.

In this case, if nanoarrow is updated, the pinned downstream package (adbcdrivermanager) may no longer pass the test.