[R-pkg-team] Bug#1039645: Seems we need a transition for r-base instead of lots of single bugs against single packages (Was: Bug#1039645: r-cran-epi: autopkgtest failure with r-base (4.3.1-1))

[Dirk Eddelbuettel]

On 28 June 2023 at 14:03, Andreas Tille wrote:
| Am Wed, Jun 28, 2023 at 08:11:05AM +0200 schrieb Bas Couwenberg:
| >  189s   DLL requires the use of native symbols
| 
| I wonder, whether all those bugs against single r-* packages are
| sensible.  

Yes they are. Those are bugs in the packages holding up the r-base package.
So I appreciate e.g. the bug report #1039633 against r-bioc-bioccheck which
happens to be the first package in the absurdly long list of 'excuses'
against r-base. (I didn't bother checking all other ones. I clicked on one or
two, they do not make sense to me.)

| As far as I can see we simply need a transition for this r-base upgrade.
| Am I missing something?

We go through this each release cycle. You believe you know R and CRAN
packages better than R Core and CRAN.  Generally speaking, that is not true.

We do find occassional bugs because we run a wider hardware span but most of
the time we are just creating busy work for ourselve.

Dirk

PS I continue to note that you can in fact trust CRAN if you do your homework
and don't randomly mix current and not-current packages. An illustration is
provided by r2u project which contains about 2 x 20k binaries (for amd64)
covering each of the two most recent LTS releases as full `apt` binaries. It
can be done.  See https://eddelbuettel.github.io/r2u. It had shipped over 5
million .deb packages in just over a year, and ships at least 10k each
day. Lots of automated CI jobs run it each day. You *can* and *should* trust
the CRAN dependency network.

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