[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bioconductor + R-base transition: next steps and status update

On Sun, Sep 19, 2021 at 09:46:11AM -0500, Dirk Eddelbuettel wrote:
> On 19 September 2021 at 19:39, Nilesh Patra wrote:
> | I was also looking at packages to get r-base migration fwd, and so far r-cran-tmb and r-bioc-scuttle have been fixed.
> Thanks.
> | So TODO:
> | 
> | => If you could ask ftp masters to accept packages, that'd be cool. I've already pinged in the IRC channel.
> | => Look at the remaining bioc failures and fix
> | => Updating a few left-over CRAN packages can help r-base transition move ahead - like knitr, unitizer etc.
> |    But since they are relatively important packages, we need to account for breakages with these too.
> Several of these transition blockages for r-base-core appear to be from
> packages that are behind upstream. Looking at
> https://qa.debian.org/excuses.php?package=r-base
> bbmle is behind 1.0.24 upstream
> devtools 2.3.2 is behind 2.4.2 upstream
> knitr 1.33 is behind 1.34 upstream
> parsetools 0.1.3 is no longer on CRAN as of 2020-01-24
> processx 3.4.5 is behind 3.5.2 upstream
> svglite is behind 2.0.0 upstream
> tikzDevice is current 
> TMB 1.7.21 is current
> unitizer 1.4.12 is behind 1.4.15 upstream
> vegan 2.5.7 is current

We are aware of packages that are lagging behind upstream[1].  After the
Bullseye release the list had featured about 360 packages.  At the time
of writing we are at 20 packages (the list is not fully updated right
now).  There are some packages remaining for known reasons (for instance
processx as discussed with upstream[2] and which has several rdepends in
our list) and several packages did not went smoothly due to either build
or test suite issues or missing new dependencies (some of these are
remaining in new).
> For tikzDevice we know R 4.0.0 imposed a rebuild for graphics devices (and R
> Core decided not to call for a formal ABI breakage which I concur with on
> balance but we _could_ of course gone all in here requiring everything to be
> rebuilt; I too think that would have been overkill) so a simple rebuild may do.

A "simple" rebuild is called a transition in Debian terms and you was
told so in the past and this should have happened in a coordinated way
for r-base 4.1.1.
> PS FYI A month ago, I actually received an email from an R Core member and
> CRAN co-founder who was wondering why the new r-base migrate would not
> migrate.  I can only say that the matter is not under my control.

You might like to tell this R Core member which is kindly invited to CC
such e-mails to our list that you unfortunately forgot to coordinate the
transition.  I do not think that finger-pointing to people you claim to
depend from is enhancing anything.

Kind regards


[1] https://salsa.debian.org/r-pkg-team/maintenance-utilities/-/blob/master/outdated_r-packages.txt 
[2] https://github.com/r-lib/processx/issues/317


Reply to: