Hi!
Efraim Flashner <efr...@flashner.co.il> skribis:
> If I understand it correctly, as part of `guix pull' we get the latest
> package definitions, but `guix' and `guix-daemon' are at the
> guix-snapshot version, aka 0.11.0-4. If instead `guix-daemon' was from
> the tip of master then it'd be at the equivalant of running
> './pre-inst-env guix-daemon --build-users...', which would have all
> these changes.
What ‘guix pull’ does is fetch the latest code, build *the Scheme
subset* of that code, and install it in ~/.config/guix/latest.
Thus, it gives you the latest package recipes as well as the latest
‘guix’ sub-commands.
What it does not give you is:
1. The latest C++ code (guix-daemon, guix-register).
2. The latest locales.
3. The latest elisp code.
4. The latest dependencies (the Guile that appears in the shebang of
the ‘guix’ command, zlib, Guile-SSH, Guile-JSON, etc.)
It worked OK when Guix was self-contained, and assuming people would
update guix-daemon through other ways (‘guix system reconfigure’ on
GuixSD). But now we see that these shortcomings are starting to bite.
So I think what we need to do is for “guix pull-ng” to build and install
a complete ‘guix’ package, and to manage it pretty much like other
packages is managed, except not in the user’s main profile (because that
could lead to undesirable behavior, where upgrading Guix creates a new
generation, or, in theory, unrecoverable problems, where you cannot
roll back because previous generations use an old Guix that does not
understand the new manifest format.)
The difficulty is that ./configure && make && make install in Guix takes
some time, and we probably wouldn’t want to do that on each ‘guix pull’
invocation (esp. with Guile 2.2’s compilation times.)
So we may have to provide substitutes of Guix itself, and arrange so
that ‘guix pull’ pulls up to a tag for which we have substitutes.
Ideas welcome! See <https://bugs.gnu.org/22629>.
Ludo’.
