Removal of S.h (was: Re: R 4.2.0 suggests a rebuild of graphics packages)

[Johannes Ranke <johannes.ranke@jrwb.de>]

Am Montag, 25. April 2022, 10:35:57 CEST schrieb Andreas Tille:
> Hi,
> 
> Am Mon, Apr 25, 2022 at 09:32:49AM +0200 schrieb Johannes Ranke:
> > > That would require rebuilding everything.  What about adding a new
> > > r-ge-api-15 that can be bumped independently of r-api-*?
> > 
> > there are two issues: The R Graphic API which we are discussing in this
> > thread, and the removal of S.h from r-base, which Andreas reported in
> > another thread already (and which should be discussed separately I
> > think).
> I agree that we have two different issues.  However, since we need an
> r-api-* bump anyway (IMHO) 

I was not aware that you are suggesting an API bump for R 4.2.0, for me this 
was not clear from your mail from your 13 April to debian-r.

Regarding the removal of S.h, the R 4.2.0 NEWS file states:

* The header S.h which has been unsupported since Jan 2016 has been
      removed.  Use R.h instead.

This suggests that R core sees this as a bug in (bioconductor) packages still 
using S.h, and not as an API change.

It seems to me, the situation being as it is, the easiest way to fix 
bioconductor in unstable and testing is to upload the new versions scheduled 
for April 27 before r-base migrates to testing. Not exactly clean, but bumping 
the API now would require managing a transition and rebuilding hundreds of 
packages that do not have an issue, right?

As you mentioned, stable users will not be affected by the removal of S.h. 
Unless they install backports from CRAN (which most R users on stable probably 
do) and have bioconductor packages from Debian installed (which I need to 
deprecate on the CRAN page obviously).

Kind regards,

Johannes

> we can delay the creation of r-ge-api-*
> which might be discussed if this and only this is needed.
> 
> > Regarding graphics packages, adding a new tag has been discussed a bit on
> > another list (r-sig-debian) - maybe now is a good time that we have a list
> > of affected packages.
> 
> That's definitely good to have anyway.
> 
> Kind regards
> 
>       Andreas.