[Rcpp-devel] [External] Re: CRAN package Rcpp

[Kurt Hornik]

>>>>> Dirk Eddelbuettel writes:

> On 31 March 2026 at 19:03, Kurt Hornik wrote:
> | Of course, this is "only a NOTE" which normally we would not ask to fix
> | immediately, but in the course of the next regular update.  However, as
> | I wrote in my original message, about 300 CRAN packages are currently

> You could consider silencing the NOTE now if it goes to far. Or add a
> whitelist of tolerated NOTEs at package update. As I understand, you use
> environment variables for that type of conditioning for other
> 'choices'.

Luke can speak for himself, but I guess we really want package code to
stop using R_UnboundValue "as quickly as possible" ... it was never part
of the API, and should never have been used in package code.

We can always do an NMU for Rcpp if a hotfix release is too much trouble
on your end?

Best
-k

> By not doing that, I think you are the one forcing a 'five day hotfix'.

> | getting the R_UnboundValue NOTE via Rcpp, and their regular updates
> | would get blocked by this (or require additional manual processing by
> | the CRAN submission team).  It would really be great if this could be
> | avoided ...

> Yes. The middle ground of 'the repository maintainers reserve the right to
> apply patches' always struck me as desirable (just how a Debian package
> typically carries a tar.gz with diffs, often just debian/ but allowing for
> changes 'as needed').

> I believe I have mentioned this, or even advocated for it, decades ago. Of
> course it went nowhere. Proposals are cheap, implementating a rigorous
> procedure takes effort and nobody has spare time.

> We still have to think through how to best propagate this. Sticking it into a
> subdirectory of src/contrib/ is in fact awfully close to a fully blessed
> release.  Which I with the maintainer responsibility of over 3000 direct
> reverse dependencies would really avoid if I could. Yet at the same time we
> may also need to make it available to other 'builder' like r-universe or
> bioconductor.

> Dirk

> -- 
> dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org