unofficial mirror of bug-guix@gnu.org 
 help / color / mirror / code / Atom feed
From: Leo Famulari <leo@famulari.name>
To: Christopher Howard <christopher@alaskasi.com>
Cc: 24993@debbugs.gnu.org
Subject: bug#24993: Documentation: 'guix pull' needed during SD installation
Date: Tue, 22 Nov 2016 23:46:07 -0500	[thread overview]
Message-ID: <20161123044607.GA23298@jasmine> (raw)
In-Reply-To: <7d52d8ee-c253-685b-1871-f908850ee606@alaskasi.com>

On Tue, Nov 22, 2016 at 01:25:57PM -0900, Christopher Howard wrote:

Welcome Christopher!

> In the online installation docs at
> <https://www.gnu.org/software/guix/manual/html_node/Proceeding-with-the-Installation.html#Proceeding-with-the-Installation>,
> please insert the command 'guix pull' before the "guix system init"
> command. Otherwise installation can fail due to missing binary packages,
> which creates confusion for newbie installers like myself. Thank you!

Can you give more detail about the problems you ran into? We want `guix
system init` to "just work".

In general, if some binary fails to be substituted [0], adding
--fallback to the command should cause the package to be built from
source, working around the issue.

I think that running `guix pull` before `guix system init` is not the
right choice for newbies, although there are some trade-offs [1].

Most new users will be installing from the binary GuixSD installer
offered on our web site. This installer is built from a Git commit that
we have tested to ensure that everything should work. We strive to keep
our master branch "deployable", but of course we make mistakes
sometimes. `guix pull` draws from the HEAD commit of the master branch,
and so new users might end up with a broken system as their first
experience.  GuixSD is extremely robust once installed — you can always
roll-back — so it's a good idea to initialize from a known good commit
and then update.

Additionally, it's likely that we will not yet have built binary
substitutes for the most recent changes on the master branch, so new
users will end up building some things from source if they use `guix
pull`.

[0] Guix is a hybrid of build-from-source and binary package management
systems. It's really a build-from-source distro, but we offer so-called
"binary substitutes", and they are transparently substituted for a
source build if they are available and the user has authorized our
substitutes server. But, if Guix expects a package to be substituted
and something goes wrong, the action will fail. Using --fallback works
around this and builds from source even when the substitution fails.

[1] I think the main drawback of installing from the release tag without
`guix pull` is that the initial generation of the GuixSD system will be
lacking important upstream bug fixes. I think users should `guix pull &&
guix system reconfigure` immediately after initializing the system. Guix
actually nags users to do this:

http://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/system.scm?id=08b3e4a97066c9baaf39e3df7c2dd9c39e693ead#n577

  reply	other threads:[~2016-11-23  4:47 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-22 22:25 bug#24993: Documentation: 'guix pull' needed during SD installation Christopher Howard
2016-11-23  4:46 ` Leo Famulari [this message]
2016-11-23 16:46   ` Christopher Howard
2016-11-23 17:25     ` Christopher Howard
2016-11-23 20:29       ` Leo Famulari
2016-11-28 17:45         ` Christopher Howard
2016-11-29  2:33           ` bug#24993: System installer grows brittle with time Leo Famulari
2016-11-29  8:44             ` Efraim Flashner
2016-11-29  9:17               ` David Craven
2016-11-29 14:44                 ` Ludovic Courtès
2016-11-29 14:42             ` Ludovic Courtès
2017-11-12 20:30         ` bug#24993: System installer grows brittle as substitutes for the release disappear Ludovic Courtès
2017-11-12 20:49           ` Leo Famulari

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20161123044607.GA23298@jasmine \
    --to=leo@famulari.name \
    --cc=24993@debbugs.gnu.org \
    --cc=christopher@alaskasi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).