Hi Ricardo,
thanks for answering, so basically this is equivalent to find the generation of commit 65956a... and invoking guix-generation-x to install guile-json. Yes, I see why this it's better than using "guix package -i *" and it relates well to my other question about profile -> packages definitions generation. Just write manifests, instantiate them and when it's time to migrate the pacakges definitions will already there. What happens if you then do "guix package -i guile-json" or if somewhere in the future "guix package -U" after a pull? It will honor the manifest or just install the guile-json on the package definition? I don't know if I can make my mind on what sort of behaviur should be best but maybe I'm more towards the idea that a manifest should take precedence, maybe with an override flag. Anyway I can try and check later what guix does. Thanks! and have a happy new year eve. Ricardo Wurmus <[email protected]> writes: > Inferiors work, but you’d use them in manifests. The idea is to install > the package with an old version of Guix, but to do it in code instead of > manually. Here’s an example: > > (use-modules (guix inferior) (guix channels) > (srfi srfi-1)) ;for 'first' > > (define channels > ;; This is the old revision from which we want to > ;; extract guile-json. > (list (channel > (name 'guix) > (url "https://git.savannah.gnu.org/git/guix.git";) > (commit > "65956ad3526ba09e1f7a40722c96c6ef7c0936fe")))) > > (define inferior > ;; An inferior representing the above revision. > (inferior-for-channels channels)) > > ;; Now create a manifest with the current "guile" package > ;; and the old "guile-json" package. > (packages->manifest > (list (first (lookup-inferior-packages inferior "guile-json")) > (specification->package "guile"))) > > You can instantiate the manifest the usual way: > > guix package -m /path/to/manifest.scm > > -- > Ricardo -- Catriel
