Re: updating list of substitutes

[Pjotr Prins <pjotr.public12@thebird.nl>]

I wish to thank you guys for bearing with my dumb-ass questions. I
think Guix is totally awesome. I have been tracking Nix for a long
time and Guix makes me happy where Nix did not.

Please keep on answering me. First because I am learning and second
because we are building a record on this ML for others to see. Your
responses have been very valuable, including Ludo creating the
tar-ball install and Ricardo's mail on the database layout.

You should know I have at least three hats, as system administrator,
as software developer and as scientist - these roles have conflicting
goals and demands which is why I can discuss direct state
modifications in the store on one end and ask for reproducible
software on the other ;).

What I have learned is that:

1. We now have a tar-ball install (awesome!)
2. The DB is the authority
3. We can't reconstruct the DB from the store 
4. Every release fixates the dependencies so if we know the exact
   release we can recreate the same dependencies 
5. We reload the list of substitutes after a fixed time

Correct?

One more below on (5):

On Tue, Apr 21, 2015 at 10:40:28AM +0200, Pjotr Prins wrote:
> > > Q1: Do we retain older builds of binaries for some time for download?
> > 
> > Yes, but the amount of time is unspecified.
> > 
> > On hydra.gnu.org it can be quite long in practice, so that would call in
> > favor of increasing the default TTL in ???guix substitute???.
> > 
> > In the longer run, we need servers to advertise their TTL (someone
> > running ???guix publish??? may have a different TTL.)
> > 
> > > Q2: Can we switch off updating list of substitutes? A command line
> > >     switch would do. '--no-update-supstitutes'
> > 
> > No.

Let me rephrase. Can we have a more lazy approach towards fetching
substitutes? Rather than a fixed TTL we could fetch the latest list on
the first failed substitute. I expect, in practise that would save a
lot of downloads which turn out to be very slow, even on decent
internet connections. It also saves load on the build server.

It does mean the initial binary/build overview on package install can
be wrong but since we retain binaries for a long time (in practise) it
would be more likely to change between releases anyway. A simple
message would do:

  INFO: failed download of substitute XXX (you may want to pull the latest release)
  INFO: substitute list downloading...
  INFO: updated substitute list. The following packages will now be built:
    1. etc etc.

I think this is actually safer and fairer than a TTL.

Pj.