[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: successful installation, but problems updating

From: Leo Famulari
Subject: Re: successful installation, but problems updating
Date: Sat, 11 Nov 2017 23:45:20 -0500
User-agent: Mutt/1.9.1 (2017-09-22)

On Sat, Nov 11, 2017 at 10:36:26PM -0500, myglc2 wrote:
> Yes, but ... the average bear using GuixSD, having internalized Guix'
> assurances that substitutes are reliably the same as what they could
> build-from-source locally, naturally assumes that substitutes will be
> used.
> Unfortunately the current "hot rolling" of updates into origin/master
> means that hydra has no way to get reliably "100% ahead" of users who
> update frequently. Further hydra does not keep a "deep set" of previous
> builds, so a user may well find themselves building old stuff. This
> treats our users to a baffling, herky-jerky experience, with local
> builds seeming to occur at random. 
> With improvements to the way changes are rolled in and to hydra, et al.,
> the "substitution fraction" that users experiences should increase, but
> will most likely never reach 100% and will remain variable.  So a user
> coming from something like debian encounters a different user experience
> that may well be disconcerting. This makes it important to find a way of
> explaining substitutes, what is happening, and what to expect, so that
> our users will feel be confident that everything is OK.
> Personally I prefer herky-jerky + "total source artistic control" +
> reliable roll-back to speedy binary-only update + unknown provenance +
> no roll back. In other words, "I drank the kool aid". I also have a
> couple speedy servers so the GuixSD builds don't interrupt my work flow.
> But I feel for the noobs on IRC whose machines have been kidnapped by
> GuixSD for huge, unpredictable, chunks of time.

All good points! Maintaining the build farm is one of really hard parts
of developing Guix, from what I've seen. I'm hopeful that we will
improve it in the next year.

> >> +When substitutes are enabled (the default) and a substitute is not
> >> +available the build will take place locally. If a substitute is
> >> +available but substitution fails, e.g., the substitute server returns
> >> +404, 504, times out, or some other unexpected problem occurs, guix stops
> >> +and reports an error unless --fallback or --keep-going options are
> >> +specified.
> >
> > To clarify, the default status of substitutes is different for Guix
> > (default disabled) and GuixSD (default enabled).
> Oh, WOW! Does the doc say that?

Yes, the installation instructions for Guix mention authorizing the
substitute signing key in step 7 [0]. So, I think it's clear that they
are not enabled otherwise.

> And, why is it different?

I don't know if there is a design choice here, but the steps required to
authorize substitutes for Guix on another distro require root. So, we
can't make it "just work" without the user elevating their privileges.
It's not the only part of our installation guide that requires root,

On GuixSD, we can control the entire system during installation, so we
enable substitutes by default.


Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]