Re: guix time-machine, broken hash in an old package definition, a workaround?

[zimoun <zimon.toutoune@gmail.com>]

Hi,

On Fri, 15 Jan 2021 at 21:18, Wiktor Żelazny <wz@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