GNU bug report logs - #32022
(new feature) Change guix pull to choose commits for which substitutes is already built by default

Previous Next

Full log

Message #8 received at 32022 <at> debbugs.gnu.org (full text, mbox):

From: ludo <at> gnu.org (Ludovic Courtès)
To: swedebugia <swedebugia <at> riseup.net>
Cc: 32022 <at> debbugs.gnu.org
Subject: Re: bug#32022: (new feature) Change guix pull to choose commits for
 which substitutes is already built by default
Date: Mon, 02 Jul 2018 15:45:37 +0200

Hello swedebugia,

swedebugia <swedebugia <at> riseup.net> skribis:

> I would like it to be easy for newcomers to do the right thing when pulling.
>
> I suggest we by default give guix pullers a bit more information and interaction.
> Something like this:
> "Checking for newly built derivations of guix at hydra.gnu.org...
> (table)
> Date            Commit         Succeeded for x64?
> 28/6            54d84d8        yes
> ... 
> ... 
> ... 
>
> Pulling based on default commit selection scheme (see --help for details) 
> Most recently built commit  is x4678x85 built x hours ago. 
> Continuing in 10 seconds...
> Press ctrl+c to abort. "

Any strategy that makes it easy to update to an “old” Guix revision is
risky: one could easily tweak the user into using an old revision that
lacks an important security fix.  So that’s not an option to me.

Furthermore, note that people may choose not to use substitutes.  The
proposed changes wouldn’t help them.

The problem we’re trying to address here is ‘guix pull’ slowness.  We
can address it in several ways:

  1. Provide substitutes in a timely fashion.  We do that on
     berlin.guixsd.org; hydra.gnu.org now provides substitutes, but not
     in a timely fashion.  We should arrange to make them more reactive
     so that you’re unlikely to have to build things from source, though
     we can’t entirely eliminate situations where you do have to build
     part of the stuff from source.

  2. Break up the build work that ‘guix pull’ does into reasonably-sized
     derivations.  (guix self) is a step in that direction, but as you
     know there are still big derivations that have to compile a whole
     lot of package modules.  We could split that further.

  3. Make Guile’s compiler faster.  I think there’s still room for
     improvement and that would benefit everyone.

IMO we should really work on these fronts rather than putting users at
risk just to paper over these performance issues.

Thanks,
Ludo’.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.