Building R under Linux - library dependencies
Docker R containers are north of 250 MB. I have checked experimentally that you can trim R down to 16 MB (!) and you'll still be able to execute it (though with warnings). That *is* quite a difference, especially when deploying small applications.
?
... I would guesstimate the libraries required to run R with any useful set of libraries is quite a bit bigger than the cited 16M .......?
? Maybe. The minimal usable subset is about 37 MB, add a few custom libraries, code of your application etc... But it's *still* much less than 250 MB. ?
Sure, package dependencies would be great as well - at least you'd be sure that users of, say, Debian-based distros will be able to run this portable R, as long as they've installed the required libraries. But notice that in your example package versions equal *or greater* than listed are required - so if someone has upgraded their system, they still will be able to run that R. With a version built from source you need *exactly* the same version as on the machine where R was compiled. Hence my question: how come the precompiled distribution of R has "less strict" library requirements than manually compiled versions?
?
Package managers don't usually cite 'less than' versions for packages - because how do you assert a version that won't work when it hasn't been released yet?
I meant that manually built versions of R (at least those compiled by me) are fixed at a certain version of dynamic libraries - the same as installed on the machine R was compiled on. You can't run this compiled R on an upgraded configuration. ?
You could go on a tear and build statically linked versions of R-with-everything-you-need, and maybe avoid the library madness... but this is sort of a fool's errand and a huge consumer of time.? OS vendors and compiler developers have stopped doing things that way for reasons.... it's much simpler to reduce duplication and make everything work - while allowing for patching out security issues - when you are *just slightly* more flexible.
Why link the libraries statically? Most Linux distributions make symlinks to dynamically linked libraries - so you have for example libicuuc.so that links to libicuuc.so.XX (where XX is the version number). Why not rely on these generic names? ?
Doing this stuff with a container is very much the easiest route, if you actually want it to be completely portable.? You're certainly welcome to start with an Alpine Linux base and add R on top and then start paring... but I start to not understand the point, somewhere in there.... ?it's a lot of time spent on something that doesn't seem that beneficial when you've got (even fairly reasonably modern) hardware that can deal with a tiny bit of extra bloat.? SD cards and USB sticks are pretty cheap everywhere, now, aren't they? I could say, maybe, putting time into this as some kind of retrocomputing project... but probably not otherwise.
Potential users who would have to download 250 megabytes beg to differ ;-) Best, -p-