R: update to 4.4.2
Testing the changes
- I tested the changes in this PR: YES
Local build testing
- I built this PR locally for my native architecture, (x86_64)
See info in #50514 and #52731. Honestly speaking, I have no idea if rebuilding is required and never had enough motivation to do that myself. IMO updating R base & possible libs, then removing all outdated packages would be better than carrying an old R release.
IMO updating R base & possible libs, then removing all outdated packages would be better than carrying an old R release.
https://github.com/void-linux/void-packages/pull/42704 i've done that before. but no one cares. no review, no comment, except bot 😔
Sorry to hear that. That's a lot of work😇.
Nowadays I just install those weird makedeps once for all and let R build libs from source automatically.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.
Although it's unlikely you'd update it, 4.4.3 is available and 4.5.0 scheduled for 2025-04-11.
I wish I knew how to use the work you've done; being on 4.3 is blocking all sorts of things, to the point I may just leave Void if this is how things work here...
f this is how things work here...
Sadly it is. If no Void member is interested in your PR it would take ages to have it merged.
FWIW I manage r via mise asdf-r plugin now. This way it's distro-agnostic but I did not try on Void-musl.
# install makedeps
# needed ones
xi ncurses-devel libhistory8 readline-devel libXmu-devel libICE-devel libSM-devel libXt-devel tcl-devel libXScrnSaver-devel libXft-devel tk-devel
# missing in template, compilation would still succeed w/o them
xi ffmpeg-devel libdeflate-devel
# install r
R_EXTRA_CONFIGURE_OPTIONS="--enable-R-shlib --with-lapack --enable-memory-profiling" mise install r
mise use -g r
@dazed1
I wish I knew how to use the work you've done
My https://xbps-src-tutorials.github.io/pr-testing-tutorial.html might be of help.
Also, is this you? Just curious.
@dazed1
I wish I knew how to use the work you've done
My https://xbps-src-tutorials.github.io/pr-testing-tutorial.html might be of help.
Also, is this you? Just curious.
yes, and I had to explain to my wife (the scientist I unretired from being a unix/whatever guy for) how annoying it was that there were so many packages that think something that isn't terribly old, is unacceptable. Back in my day, the old man says, you might require a major version change for new features your tool uses but if your tool is a dependency for other tools, you don't do things that require the latest minor versions; it just causes chaos. But 4.3.1 is legit somewhat old at this point (we're at 4.5.1 now). But I couldn't cleanly install Matrix, or various other dependencies, because R is too old, which means I couldn't cleanly install the packages I want, without just stomping the void-provided R.
See info in #50514 and #52731. Honestly speaking, I have no idea if rebuilding is required and never had enough motivation to do that myself. IMO updating R base & possible libs, then removing all outdated packages would be better than carrying an old R release.
Yeah, updating all the packages that depend on R is a major hassle (particularly with the release schedule of some CRAN packages). It's happened to me once or twice that a package updated in a PR has a newer version before the PR is even merged (see the last time I attempted to update R for void).
I've been thinking about this for a while and it would require more involved discussion but honestly I would be in favour of doing it the way distros like gentoo do it and drop all the R-cran-* packages and just maintain base R and allow users to install packages. But I am unsure if that would break any workflows for people.
unsure if that would break any workflows for people.
It should be fine (for VSCode at least, not sure about RStudio or Jupyter). I've been using mise-r for a few months and everything just works after setting .libPaths in .Rprofile (so I don't have to reinstall everything after minor update). I would expect a similar experience for a r-base only distro package.
Pull Requests become stale 90 days after last activity and are closed 14 days after that. If this pull request is still relevant bump it or assign it.