Hi, On Fri, 15 Jan 2021 at 21:18, Wiktor Żelazny <w...@freeshell.de> wrote: > On Thu, Jan 14, 2021 at 09:29:48PM +0100, zimoun wrote:
>> you will not get the exact R packages as they were at the time of >> d81fb2a; > > Can you, please, elaborate on that? Do you mean by that that the > different r-foreign will result in a different r, and that will Yes. Bit-to-bit different but you can expect functionally similar. > propagate to the packages, as they depend on r? But R does not compile > the R code in the packages while they are being installed, does it? Am I > missing something? If it were the issue wouldn’t it occur also in your > `./pre-inst-env` approach? Same root of problem, same consequence. :-) This upstream bad practise is not fixable; whatever the mean. > A new idea: I just checked “CRAN Time Machine” at MRAN. The tarball with > the 0g4mi101srjbl17ydb2hl3854m3xj0llj6861lfr30sp08nkqavl hash is there. > I guess I can use `build --with-source=` now, maybe even `environment > --with-source=r-foreign=`? Perhaps a more elegant solution would be to > define r-foreign-fixed, as you describe above, yet this time leaving the > hash, but changing the URL. Are there philosophical reasons for not > using MRAN? Oh, thanks for the pointer. Yeah, in this case it is possible to use --with-source, maybe combined with another trick to populate your store with the expected by d81fb2a tarball. And then simply use “guix time-machine” as usual. The API needs to be checked, maybe it should be possible to automatise the fallback: try Guix build farm, then upstream, then SWH, then CRAN for R build system. Maybe. :-) All the best, simon