Skip to content

R 4.1.0 and Graphics Packages

4 messages · Dirk Eddelbuettel, Johannes Ranke

Original
Johannes Ranke
# 
Hi all,

The NEWS for R 4.1.0 contain the note:

- The graphics engine version, R_GE_version, has been bumped to 14 and so 
packages that provide graphics devices should be reinstalled

And indeed, I just ran into this and got a 

  Graphics API version mismatch

error when using the tikzDevice package with my fresh CRAN backport of R 4.1.0 
that Dirk uploaded to experimental. The error went away after reinstalling 
tikzDevice.

For CRAN backports users, I just added a note on the Debian page

  https://cran.r-project.org/bin/linux/debian/#debian-bullseye-testing 

(it will take a while for the mirrors to sync).

Before the r-api system was introduced, I used to set up fresh repositories 
when R introduced breaking changes, in order to avoid that an apt-get upgrade 
breaks installed R package functionality. This one slipped by my attention.

For the Debian R packages, I think we should find out which of the R packages 
in the Debian archive are affected by this (r-cran-rgl, r-cran-svglite, r-cran-
vdiffr which embeds svglite, ggplot2, ...) and add versioned Breaks.

Or should the r-api Version be bumped from r-api-4.0 to r-api-4.1?

Cheers,

Johannes
Dirk Eddelbuettel
#
On 21 May 2021 at 10:56, Johannes Ranke wrote:
| Hi all,
| 
| The NEWS for R 4.1.0 contain the note:
| 
| - The graphics engine version, R_GE_version, has been bumped to 14 and so 
| packages that provide graphics devices should be reinstalled
| 
| And indeed, I just ran into this and got a 
| 
|   Graphics API version mismatch
| 
| error when using the tikzDevice package with my fresh CRAN backport of R 4.1.0 
| that Dirk uploaded to experimental. The error went away after reinstalling 
| tikzDevice.

Eeek. Didn't think of that.
 
| For CRAN backports users, I just added a note on the Debian page
| 
|   https://cran.r-project.org/bin/linux/debian/#debian-bullseye-testing 
| 
| (it will take a while for the mirrors to sync).
| 
| Before the r-api system was introduced, I used to set up fresh repositories 
| when R introduced breaking changes, in order to avoid that an apt-get upgrade 
| breaks installed R package functionality. This one slipped by my attention.
| 
| For the Debian R packages, I think we should find out which of the R packages 
| in the Debian archive are affected by this (r-cran-rgl, r-cran-svglite, r-cran-
| vdiffr which embeds svglite, ggplot2, ...) and add versioned Breaks.
| 
| Or should the r-api Version be bumped from r-api-4.0 to r-api-4.1?

I would prefer not, and don't think it is called for. But then I often argued
for a more 'laissez-faire' approach that others (on the other list, i.e. debian-r). 

Once the release is made, I will put R 4.1.0-* into unstable and rebuild at
least all the packages from experimental.  Me thinks we can handle this via
the normal bug track mechanism. But the backport may have extra issue. But
maybe your list of 'has graphics' packages is good enough?

Dirk
3 days later
Johannes Ranke
# 
Am Freitag, 21. Mai 2021, 19:03:59 CEST schrieb Dirk Eddelbuettel:
A more systematic way would be to have R 4.1.0-2 provide r-graphics-api_14 and 
only upload packages providing graphics devices that have a respective 
dependency from now on. But I don't know if it's worth the trouble.
At this point I don't really see what we can do other than spreading the word 
so the backports users can quickly address the problem by reinstalling the 
affected packages.

Cheers,

Johannes

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Dirk Eddelbuettel
    

    

      
      #
    

  


  

      
On 25 May 2021 at 08:47, Johannes Ranke wrote:

        
| A more systematic way would be to have R 4.1.0-2 provide r-graphics-api_14 and 
| only upload packages providing graphics devices that have a respective 
| dependency from now on. But I don't know if it's worth the trouble.

If you wanted to you could do that locally for just the backport. 
 
| At this point I don't really see what we can do other than spreading the word 
| so the backports users can quickly address the problem by reinstalling the 
| affected packages.

We can rebuild all the affected packages.  An 'apt update; apt upgrade' would
then pull them in.  That is generally my preferred approach.

Dirk