help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Wiktor Żelazny
Subject: Re: guix time-machine, broken hash in an old package definition, a workaround?
Date: Fri, 15 Jan 2021 21:18:59 +0100

On Thu, Jan 14, 2021 at 09:29:48PM +0100, zimoun wrote:

> But I am doubtful that is what you really want.  Instead, I guess you
> want packages that depends on r-foreign, as r for instance.  Let take
> r-hmisc and r-rio for simplicity.

Hi,

Thank you for the great explanation.

> --8<---------------cut here---------------start------------->8---
> $  guix time-machine --commit=d81fb2a \
>         -- build -L pkgs r-hmisc r-rio --with-input=r-foreign=r-foreign 
> […]
> guix build: avertissement : spécification du paquet « r-foreign » ambiguë     
>   
> guix build: avertissement : choix de r-foreign@0.8-75 à l'emplacement 
> pkgs/fix.\
> scm:8:2
> […]
> /gnu/store/b64i6d3vsyss7154j1dgvc8rr7k4wzqs-r-rio-0.5.16
> /gnu/store/w0lpix3yjlzsb9kh32hsg0lp1igrk1y9-r-hmisc-4.3-0
> --8<---------------cut here---------------end--------------->8---
>
> If you want you avoid the ambiguity, you can instead rename the package
> as you want, for instance r-foreign-new and just type:
>
>   --with-input=r-foreign=r-foreign-new

This actually looks like one of the approaches that I tried before
starting this thread, but with `environment` substituted for `build`. Is
it possible that `guix environment` ignores --with-input? `guix
environment --help-transform` lists it.

It is also possible that I did something a bit differently than in your
example (devil in the details). I would need to compare the presented
approach with mine.

> 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
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?

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?

WŻ

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]