Hi Mauritz
Mauritz Stenek <mste...@disroot.org> writes:
> Suppose you have these packages in your environment:
>
> A@old
> B
> C
>
> where `A` is pinned to the `old` version, which is not in the latest
> channel versions -- as per `guix describe`; the latest versions of
> both `B` and `C`, however, are in the latest channel versions but
> *not* in the channel versions where `A@old` is defined.
>
> How, then, is this environment replicable without some hacky
> gymnasitcs?
>
> What am I missing?
Your hunch is corect. Without knowing the Guix commit that the
environment/profile was built with, you would not be able to reproduce
the profile exactly.
There's two options I know of:
1. Guix time-machine. e.g.
guix time-machine --commit=XXX -- package -m manifest.scm
a. This will create a profile containing the exact packages at that
moment in time, including A@old.
b. All packages will be at whatever version the corresponding
Scheme package variable is at for that commit. See (info "(guix)
Invoking guix time-machine"). Probably not the best idea to use
long term.
2. Inferiors. This provides a mechanism for mixing and matching A@old
from commit XXX with packages B and C from commit YYY. See (info "(guix)
Inferiors").
a. To my knowledge this won't replace dependencies for B or C if
they depend on A@old. B and C would use the "primary" channel's A.
You probably could modify B and C to replace A with A@old though.
As you saw, A@old doesn't have any fancy logic for "go back to the most
recent Guix commit that has A@old". It's just a convenient way to
specify which version of package A to install when multiple are
packaged.
--
Take it easy,
Richard Sent
Making my computer weirder one commit at a time.
