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

[zimoun]

Hi,

On Thu, 14 Jan 2021 at 20:00, Wiktor Żelazny <wz@freeshell.de> wrote:

>> About the hash mismatch, game over with time-machine.
>
> Are you sure? I remember a situation where a package was defined in my
> private channel. Then, someone committed a definition for the same
> package to guix, but the definition in the private channel was still
> given a priority while performing `guix package` operations.

It depends on what you want at the end: only the package r-foreign or
some packages depending on r-foreign.

For only the package r-foreign, it is trivial:

--8<---------------cut here---------------start------------->8---
$ cat pkgs/fix.scm                    
(define-module (fix)                                                            
  #:use-module (guix packages)                                                  
  #:use-module (guix download)                                                  
  #:use-module (guix build-system r)                                            
  #:use-module (gnu packages statistics))                                       
                                                                                
(define-public r-foreign-fixed                                                  
  (package                                                                      
    (inherit r-foreign)                                                         
    (name "r-foreign")                                                    
    (version "0.8-75")                                                          
    (source                                                                     
     (origin                                                                    
       (method url-fetch)                                                       
       (uri (cran-uri "foreign" version))                                       
       (sha256                                                                  
        (base32                                                                 
         "1c888wrn9xf94lp7w9kjw5l8fnarrkv5pi1px5rfnybm1qlysdx5"))))))

$  guix time-machine --commit=d81fb2a -- build -L pkgs 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/d1vfvx9y6cada0fcl8adx0gslk8iz4sc-r-foreign-0.8-75
--8<---------------cut here---------------end--------------->8---

And you can put this package in a manifest file as you did and simply
run:

  guix time-machine -C channels.scm \
       -- environment -C -L pkgs -m manifest.scm

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.

As you see, there is an ambiguity.  If the symbol ‘r-foreign‘ is defined
in the module (fix), then the module (gnu packages statistics) cannot be
used so you need to declare all the recipe.  And if ’inherit‘ is used
then the symbol ‘r-foreign‘ cannot be defined twice.

Moreover, the symbol you really want is the one in (fix).  But the
package r-hmisc refers to the one in (gnu packages statistics).  And the
package r-rio also refers to the one in (gnu packages statistics)
because on the top of the file, as you can see, there is #:use-module
(gnu packages statistics).

Game over? :-)  No wait…

> If I don’t manage to make the different channels “communicate with each
> other”, I can try substituting the input r-foreign definition from the
> guix channel with one with another version, which is even closer to the
> theme of the cited thread. I don’t care much about the r-foreign
> version, but I care about the version (and the binary) of r and the R
> package stack that I use in that environment, and r happens to depend on
> r-foreign as an input.

…this trick works:

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

> For testing a solution to the hash mismatch problem, it suffices to
> build r, which uses r-foreign as an input. I will decide later about
> what to do next.

Well, first be careful because you will rebuild a lot of R packages
because r-foreign is almost a root package.  Second, you will not get
the exact R packages as they were at the time of d81fb2a; which is for
me Game Over! :-)


Hope that helps,
simon