Re: successful installation, but problems updating

[myglc2]

On 11/11/2017 at 20:29 Leo Famulari writes:

> On Sat, Nov 11, 2017 at 10:29:30AM -0500, myglc2 wrote:
>> On 11/10/2017 at 15:30 Chris Marusich writes:
>> > Thank you for the clarification.  This is what I did not understand.  I
>> > read the manual and got the impression that when --fallback has not been
>> > given, if a given substitute cannot be found (regardless of whether or
>> > not a substitute server claimed to provide one), then Guix will not
>> > build it.  I see now that my understanding was mistaken.
>> 
>> I had this mistaken impression too.
>
> It's important to remember that Guix is a build-from-source system. The
> use of pre-compiled binaries is an optimization made possible by the
> functional package model.

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.

>> +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?

And, why is it different?